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Commissioner for Patents 
BOX DAC 
Attn: Nancy Johnson 
Washington, D.C. 20231 

RESPONSE TO DECISION REFUSING STATUS UNDER 37 CFR 1.47(a) 

Dear Sir: 

This response is sent pursuant to a decision refusing status under 37 CFR 1.47(a) and 
mailed May 31, 2002. The undersigned responds to the deficiencies noted with respect to the 
decision as follows: 



I. Provide further details on the circumstances of the refusal 



A. Brent Parent 



Attached as Exhibit A is a package sent to Mr. Brent C. Parent on July 19, 2002. The 
package is a duplicate of one sent to him on November 16, 2001, including both the letter and the 
indicated attachments. The attachments comprise complete copies of U.S. patent applications for 
Dana reference numbers 5397 DCCSP (U.S. Application Serial No. 09/714,702) and 5672 
DCCSP (U.S. Application Serial No. 09/990,911), and then currently executed versions of 
combined Declaration and Power of Attorney for each of the applications by other co-inventors 
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for the applications. Once again we tabbed where Mr. Parent was requested to sign his name as 
an inventor for each of the applications on the applicable Combined Declaration and Power of 
Attorney documents. 

As set forth in the letter, we confirmed that Mr. Parent in fact received the package that 
sent on November 16, 2001. We further confirmed that he left the undersigned a voice mail on 
November 20, 2001, acknowledging receipt of the package and providing his cell phone number 
and home phone number. Moreover, the letter confirmed Mr. Parent received a carbon copy of a 
message Andy Suhy sent to the undersigned on November 26, 2001 concerning the similar 
package he received. (Exhibit B). The undersigned responded to both Mr. Parent and Mr. Suhy 
promptly after receiving the e-mail message. (Exhibit C) 

The letter goes on to confirm that the undersigned had a telephone discussion within a 
day or so after the e-mail message was from Mr. Suhy and the undersigned responded. The 
discussion concerned the package provided to Mr. Parent on November 16, 2001, wherein he 
again refused to execute any documents associated with his former employer Dana Corporation 
despite his obligation to do so as an employee inventor at the time the inventions were 
developed. Moreover, it was discussed that if a joint inventor refuses to join in an application for 
patent or cannot be found or reached after due diligent effort, the application may be made by the 
other inventors on behalf of himself or herself and the non-signing inventor. A refusal to sign 
the Combined Declaration and Power of Attorney is such a refusal. As part of the discussion 
discussion, Mr. Parent agreed to pass on the clarification of the reasons associated with the need 
for signatures to Mr. Suhy since he was in contact with him. 

As shown in Exhibit D, Mr. Parent received the package of Exhibit A, including the letter 
dated July 19, 2002. Mr. Parent has not contacted the undersigned in any manner. A final e-mail 
communication sent to Mr. Parent and Mr. Suhy concerning the need for their signatures on the 
requested documents is attached as Exhibit E. If a favorable response is received, an updated 
response will be promptly filed. 

In view of the foregoing, it is respectfully submitted that every reasonable effort has been 
made to provide Mr. Parent with the required documents and to request his assistance in 
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executing the Combined Declaration and Power of Attorney documents. It is further submitted 
that by the letter sent to Mr. Parent as noted above, the undersigned has confirmed additional 
specifics of the various communications such as the dates on which they took place as well as 
confirmed that Mr. Parent was provided with all necessary documents on two separate occasions, 
including with the original package sent on November 16, 2001. His refusal to sign in 
accordance with 37 CFR 1.47(a) is well documented and complies with the requirements of the 
provision. 

B. Andrew F. Suhv 

Attached as Exhibit F is a package sent to Mr. Andrew F. Suhy, Jr. on July 19, 2002. The 
package is a duplicate of one sent to him on November 16, 2001, including both the letter and the 
indicated attachments. The attachments comprise complete copies of U.S. patent applications for 
Dana reference numbers 5397 DCCSP (U.S. Application Serial No. 09/714,702) and 5672 
DCCSP (U.S. Application Serial No. 09/990,911), the currently executed versions of combined 
Declaration and Power of Attorney for each of the applications by other co-inventors for that 
application, and the Declaration and Power of Attorney Mr. Suhy originally executed for 5397 
DCCSP. Once again we tabbed where Mr. Suhy needed to sign his name as an inventor for each 
of the applications on the applicable Combined Declaration and Power of Attorney document. 

The letter confirmed that Mr. Suhy in fact received the package that was sent to him on 
November 16, 2001 at his Ohio address. As stated, the letter was not sent to the old New York 
Address since the package sent was returned for non-delivery and a confirmation written on the 
package that Mr. Suhy had moved. 

The letter further confirmed that Mr. Suhy sent the undersigned an email on November 
26, 2001, acknowledging receipt of the package. (Exhibit B). The undersigned responded to the 
e-mail promptly upon receipt. (Exhibit C). Further, in response to the email communication, the 
undersigned tried to contact Mr. Suhy on his mobile telephone using the phone number provided 
in the e-mail, but did not receive any return telephone calls. The letter also confirmed that the 
electronic mail communication was carbon copied Brent Parent. 
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Moreover, the letter confirmed that on November 20, 2001, Mr. Parent left the 
undersigned a message with both his cellular telephone number and his home number. Within a 
day or so after receiving the e-mail and responding, the undersigned spoke personally with Mr. 
Parent by phone concerning the legal obligations that both Mr. Suhy and he have to sign and 
return the Combined Declaration and Power of Attorney documents based on their employment 
with Dana Corporation at the time that the invention was developed by each of them as co- 
inventors for the indicated applications. As also explained to Mr. Parent, if a joint inventor 
refuses to join in an application for patent cannot be found or reached after diligent effort, the 
application may be made by the other co-inventors on behalf of himself or herself and the non- 
signing inventor. A refusal to sign the Combined Declaration and Power of Attorney is such a 
refusal. 

Finally, the letter confirmed that discussions by the undersigned with Mr. Parent, he 
indicated that he would pass on the clarifications that we discussed of the reasons associated with 
the need for the signature of Mr. Suhy on the enclosed papers. 

As shown in Exhibit G, Mr. Suhy received the package of Exhibit A, including the letter 
dated July 19, 2002. Mr. Suhy has not contacted the undersigned in any manner. A final e-mail 
communication sent to Mr. Parent and Mr. Suhy concerning the need for their signatures on the 
requested documents is attached as Exhibit E. If a favorable response is received, an updated 
response will be promptly filed. 

In view of the foregoing, it is respectfully submitted that every reasonable effort has been 
made to provide Mr. Suhy with the required documents and to request his assistance in executing 
the Combined Declaration and Power of Attorney documents. It is further submitted that by the 
letter sent to Mr. Suhy as noted above, the undersigned has confirmed additional specifics of the 
various communications such as the dates on which they took place as well as confirmed that Mr. 
Suhy was provided with all necessary documents on two separate occasions, including with the 
original package sent on November 16, 2001. His refusal to sign in accordance with 37 CFR 
1.47(a) is well documented and complies with the requirements of the provision. 



Page 4 



Attorney Docket No. 65678-0042 



PATENT 



n. Deficient Oath or Declaration 

The Decision included a number of objections to the oath or declaration. A supplemental 
oath or declaration is enclosed as Exhibit H. 

A. The declaration must include the citizenship of all inventors, regardless of signing 
status 

Exhibit H includes the citizenship of non-signing inventors Suhy and Prent, as well as the 
insertion of citizenship by inventor Patrick O'Brien. Mr. O'Brien has initialed and dated the 
insertion. Thus, the inventorship of all inventors is now included. 

B. Non-dated or initialized changes to Roth's residence information 

Mr. Roth has dated and initialized the change he made to his address. Mr. O'Brien has 
also provided updated address information, which he has also dated and initialed. 

C. Residence Address 

It is confirmed that the residence address is both the address where the inventors live and 
where they originally receive mail, the mailing address. 

HI. Conclusion 

It is respectfully submitted that the deficiencies and objections to as noted in the Decision 
have been addressed. Therefore, granting of the petition is respectfully requested. A one month 
extension of time may be charged to Deposit Account No. 18-0013 in the name of Rader, 
Fishman & Grauer PLLC. If there are any deficiencies associated with the filing of this response, 
they may be charged to the same deposit account. 
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If there are any questions or comments, please contact the undersigned. 



Finally, a copy of the Notice to File Missing Parts is enclosed with this Response. 

Respectfully submitted, 

Michael B. Stewart, Reg. No. 36,018 
Attorney for Applicants 
RADER, FISHMAN & GRAUER PLLC 
39533 Woodward, Suite 140 
Bloomfield Hills, MI 48304 
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Date: August 29, 2002 

Customer No. 010291 
Telephone No. (248) 594-0633 
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OFFICE OF PETITIONS 
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39533 Woodward Ave., Ste. 140 
Bloomfield Hills, Michigan 48304 
Tel: (248) 594-0600 
Fax: (248) 594-0610 




VIA FEDERAL EXPRESS 



PLLC 



Michael B. Stewart 
(248) 594-0633 
mbs@raderfishman.com 



(Signature Release - Saturday Delivery) 



July 19, 2002 



Brent C. Parent 
247 Stone Oak Court 
Holland, OH 43528 



Ref: 65678-0042 



Data: 19JUL02 
Ulgt: 1 LBS 



SHIPPING $10.67 
SPECIAL $10.27 
HANDLING $0.00 



TOTflL 



$20 . 94 



SERVICE: PRIORITY SATURDAY 
TRACK: 4702 63<37 6647 



Re: U.S. Patent Application for APPARATUS AND METHOD FOR TRACKING 
AND MANAGING PHYSICAL ASSETS 
Dana Case 5397 DCCSP; Our Ref. 65678-0037 

U.S. Continuation-in-Part Patent Application for SYSTEM AND METHOD FOR 
DISPOSING OF ASSETS 

Dana Case 5672 DCCSP; Our Ref. No. 65678-0042 



Once again, we enclose a copy of the package that we sent to you on November 16, 2001, including both 
the letter and the indicated attachments. The attachments comprise complete copies of U.S. patent applications 
for Dana reference numbers 5397 DCCSP (U.S. Application Serial No. 09/714,702) and 5672 DCCSP (U.S. 
Application Serial No. 09/990,91 1), and the currently executed versions of combined Declaration and Power of 
Attorney for each of the applications by other co-inventors for the applications. Once again we also have tabbed 
where you need to sign your name as an inventor for each of the applications on the applicable Combined 
Declaration and Power of Attorney document. 

As we both know, you in fact received the package that we sent to you on November 16, 2001. I confirm 
you left a voice mail for me on November 20, 2001, acknowledging receipt of the package and providing your 
cell phone number and home phone number. I also confirm you received a carbon copy of a message Andy Suhy 
sent to me on November 26, 2001 concerning the similar package he received. I responded to both of you 
promptly after receiving the e-mail message. 

Further, I confirm that we had a telephone discussion within a day or so after I received the e-mail 
message from Mr. Suhy and responded. The discussion concerned the package provided to you on November 16, 
2001, wherein you again refused to execute any documents associated with your former employer Dana 
Corporation despite your obligation to do so as an employee inventor at the time the inventions were developed. 
As we discussed, if a joint inventor refuses to join in an application for patent or cannot be found or reached after 
due diligent effort, the application may be made by the other inventors on behalf of himself or herself and the 
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non-signing inventor. A refusal to sign the Combined Declaration and Power of Attorney is such a refusal. As 
part of our discussion, you agreed to pass on the clarification of the reasons associated with the need for 
signatures to Mr. Suhy since you were in contact with him. 

If you have any specific questions, please contact me. Otherwise, please return executed copies of the 
Combined Declaration and Power of Attorney documents for the two cases. You can keep the applications for 
your records. For your convenience we enclose a self-addressed and stamped Express mail envelope. All you 
have to do is to put the executed papers in the envelope and drop it in an appropriate US postal service mailbox. 

In the absence of receiving the executed Declarations documents from you by July 29, 2002, we will be 
forced to conclude yet again that you will continue to refuse to sign them in accordance with your past efforts 
with respect to a number of different applications and share shall this refusal with the United States Patent and 
Trademark Office. 

If you have any questions, please contact me. 

Very truly yours, 
RADER, FISHMAN & GRAUER PLLC 

Michael B. Stewart 

MBS/amv 
Enc. 
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39533 Woodward Ave., Ste. 140 
Bloomfield Hills, Michigan 48304 
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VIA FEDERAL EXPRESS 

(Signature Release - Saturday Delivery) 



Brent C. Parent 
247 Stone Oak Court 
Holland, OH 43528 



November 16, 2001 



Ref: 65678-0037 
Dept : 



Michael B. Stewart 
(248) 594-0633 
mbs@raderfi5hman.com 



Date: 16NOV01 SHIPPING $11.37 
Wat- 1 LBS SPECIAL $10.34 
" HANDLING $8.08 



SERVICE: PRIORITY SATURDAY 
TRACK: 4702 6395 2904 



TOTAL $21.71 



Re: 



U.S. Patent Application for APPARATUS AND METHOD FOR TRACKING 
AND MANAGING PHYSICAL ASSETS 
Dana Case 5397 DCCSP; Our Ref. 65678-0037 

U.S. Continuation-in-Part Patent Application for SYSTEM AND METHOD FOR 
DISPOSING OF ASSETS 

Dana Case 5672 DCCSP; Our Ref. No. 65678-0042 
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OFFICE OF PETITIONS 



Dear Brent: 



We apologize for continuing to send papers to you when you have expressed to me on more than one 
occasion that you refuse to sign any documents associated with your prior employment with Dana Commercial 
Credit Corporation. 

We have already communicated with you concerning the above-identified 65678-0037 application. We 
have sent you a Combined Declaration and Power of Attorney, which you refused to execute. Our papers indicate 
Sat the copy of the Combined Declaration and Power of Attorney that we sent to you listed all of the inventors 
S &e Stores of all co-inventors with the exception of Andy Suhy and yourself. Nevertheless, to address a 
Potential £ued raised by the U.S. Patent Office, we re-enclose a copy of this Combined Declaration and Power of 
Attorney id again request that you execute it and return it to my attention for filing. You have already received a 
copy of the application as a result of our prior correspondence. Nevertheless, we agam enclose a copy of the 
appucation for your review. It would be greatly appreciated if you would execute the Combined Declaration and 
Power of Attorney and return it to my attention by November 28, 2001, so that we may timely file it with the 
U.S. Patent Office. For your convenience, we enclose a self-addressed, stamped envelope. 

We would also appreciate your continued assistance with respect to the above-identified 65678-0042 
application, which was filed on November 14, 2001. It is a continuation-in-part application We enclose a copy 
of the Combined Declaration and Power of Attorney and Assignment that has been executed by most of the 
mventors for the application along with a copy of the application. We would appreciate it if you could sign these 
documents and return them to us. 
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If it turns out that you are again unwilling to execute any of the enclosed documents, I would appreciate 
the courtesy of a telephone call so that I can so inform the U.S. Patent Office. My office telephone number is 
(248) 594-0633 as indicated above. If you wish to speak over the weekend, my home telephone number is (248) 
644-1863. Finally, my portable number is (248) 390-0633. 



Very truly yours, 
RADER, FISHMAN & GRAUER PIXC 




Michael B. Stewart 



MBS/amv 
Enc. 

cc: Linda Lentz (w/enc.) 

Robert M. Leonardi, Esq. (w/enc.) 
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LaL DESIGN, NATIONAL STAGE OF PCT, SUPPLEMENTAL, DIVISIONAL, 

CONTINUATION, OR C-I-P) 



As a below named inventor, I hereby declare that: 

TYPE OF DECLARATION 
This declaration is for an original application. 
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OFFICE OF PETITIONS 



INVENTORSHIP IDENTIFICATION 



. residence post office address and citizenship are as stated below, next to my name. I believe that I 
am rfflttd joint inventor of the subject matter that is claimed, and for winch a patent 1S 
sought on the invention entitled: 



My: 



TITLE OF INVENTION 
APPARATUS AND METHOD FOR TRACKING AND MANAGING PHYSICAL ASSETS 

SPECIFICATION rDENTTFICATION 



The deification was filed on November 16, 2000. I hereby authorize and request my attorney® of 
reTord mtfappTication to insert the serial number and filing date of this apphcahon « the spaces 
that follow: Serial Number 0^71470 filing Date: 11/16/00 



ACKNOWLEDGMENT OF REVIEW OF PAPERS AND DUTY OF CANDOR 

I hereby state that I have reviewed and understand the contents of the above-identified 
specification, including the claims, as amendedby any amendment referred to above. 

I acknowledge the duty to disclose information, which is material to patentability as defined in 
37, Code of Federal Regulations, § 1.56. 




POWER OF ATTORNEY 



I hereby appdafW&owing practitioner(s) to prosecute this application and transact all 
business in the Patent and Trademark Office connected therewith. 

Registration Number 36,018 



Michael B.Stewart 
Robert ML Leonardi 
Phillip A. Rotman II 



Registration Number 27,815 
Registration Number 38,290 



I hereby appoint the practitioners associated with the Customer Number provided below to 
pro^^^B^ «dto transact all business in the Patent and Trademark Office connected 
therewith. 



SEND CORRESPONDENCE TO 



Michael B. Stewart 
Rader, Fishrnan & Grauer PLLC 
39533 Woodward Avenue, Suite 140 
Bloomfield Hills, MI 48304 

Customer Number. 010291 



DIRECT TELEPHONE CALLS TO: 

Michael B. Stewart 
(248) 594-0600 



DECLARATION 



I hereby declare that ail statements made herein of my own knowledge are true and that all 
statements Se on information and belief are believed to be true; and further that these statement were 
^TSST 'knowledge that willful false statements and the like so made are punishable by fine or 
"^Section 1001 of Title 18 of the United States Code and that such wulful 
fXsXments may jeopardize the validity of the application or any patent issued thereon. 



SIGNATURES 




J. Aaron Bly 
Inventor's signature 

Date /A^-^PC? of Citizenship (/S/j 
Residence 2650 Pine Trace Drive #4, M aumee. Ohio 43537 



DaYid P. Francis 
Inventor's signature 




Country of Citizenship 




John M. Melby 
Inventor's signature 



~7 




Residence 1734 Sandalwood Drive, Tol edo. Ohio 43614 



Patrick O'Brien 
Inventor's signature 



Date J % 



i 



Country of Citizenship 



(X SA 



Residence 613 Midfield D rive. Maumee, Ohio 43537 



Brent Parent 
Inventor's signature 



Date 



Country of Citizenship 



Residence 247 Stone Oak Court Holl and. Ohio 43528 



Ryan J. Sherman 

Inventor's signature 



Date Country of Citizenship __^L 

Residence 430 E. Fifth Str eet. Perrysburg, Ohio 43551 



Andrew F. Suhy, Jr. 

Inventor's signature — 

_ x Country of Citizenship 

Date 

Residence 1471 Indian Creek Drive, Per rvsbure. Ohio 43551 
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APPARATUS AND METHOD FOR TRACKING 
AND MANAGING PHYSICAL ASSETS 

RELATED APPLICATIONS 
This application claims the benefit of U.S. Application Serial No. 09/441,289 filed 
November 16, 1999, U.S. Provisional Application Serial No. 60/166,042 filed November 17, 
1999, U.S. Application Serial No. 09/503,671 filed February 14, 2000, U.S. Application 
Serial No. 09/504,000 filed February 14, 2000, U.S. Application Serial No. 09/504,343 filed 
February 14, 2000, US Application Serial No. 09/653,735 filed September 1, 2000, and US 
Application Serial No. 09/702,363 filed October 31, 2000, the contents of which are all 
hereby incorporated in their entirety by reference. 

BACKGROUND OF THE INVENTION 
The present invention relates in general to systems for tracking and managing physical 
assets to promote the efficient maintenance of the assets while reducing cost. In particular, 
this invention relates to a computer based system for automatically gathering, analyzing, and 
delivering information relating to the maintenance of a plurality of such assets, such as a fleet 
of industrial equipment, so as to maximize productivity and to reduce the operating costs and 
administrative burdens associated with such assets. 

Many businesses operate a plurality of physical assets to assist in the performance of 
the daily activities that are required to produce goods or services. For example, a typical 
manufacturer of goods often uses a fleet of industrial equipment, such as forklifts, conveyors, 
machine tools, and the like, in its daily operations to facilitate the manufacture of goods for 
its customers. In a similar manner, a typical provider of services also often employs a . 
plurality of assets, such as computers, communications equipment, photo imaging equipment, 
and the like, in its daily operations to facilitate the performance of services for its customers. 
Traditionally, businesses have purchased such assets for use in their facilities and have 
employed staff to operate and maintain the assets in furtherance of the manufacture of goods 
or the performance of services. 

Regardless of the specific nature of the business, the operation of these assets has 
usually been considered to be somewhat ancillary to the core nature of the business. In other 
words, although the use of these assets is helpful (indeed, sometimes necessary) for the 
business to manufacture the goods or provide the services in a cost efficient manner, the 
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ownership, operation, and maintenance of such assets is not, of itself, a core function of the 
business. Consequently, the costs associated with the procurement and utilization of snch 
assets have not been traditionally monitored or analyzed by the business in great detail. 
Rather, such costs have usually been considered to be relatively fixed costs of doing business, 
and any management of such assets has been performed, if at all, by relatively low level 
employees having little training or inclination to increase productivity and reduce costs. 

Obviously, many businesses have been able to produce goods and provide services 
without actively managing the costs of obtaining and operating these assets. However, 
optimization of productivity and minimization of costs are key considerations in the modem 
business environment. Thus, it would be desirable to provide a computer based system for 
automatically gathering, analyzing, and delivering information relating to the procurement 
and utilization of a plurality of such assets, such as a fleet of industrial equipment, so as to 
maximize productivity and to reduce operating costs and administrative burdens associated 
with such assets. 

It would also be desirable to be able to provide different parties having an interest in 
the asset ready access to up-to-date real-time and historical access to the information 
associated with asset usage, maintenance, performance, and the like. For example, besides 
the business using the asset, there is often a third party maintenance organization that helps to 
maintain the asset and a leasing company acting as the true asset owner that leases the asset to 
the business. Because the leasing company lacks appropriate information concerning the 
asset, the leasing arrangement typically takes this lack of information into account as part of 
the lease transaction, often through a combination of both a fixed lease amount tied to the 
asset regardless of use, as well as a financial cushion for the benefit of the true asset owner to 
cover unforeseen problems associated with the asset including over-use and improper 
maintenance. 

It would also be desirable to be able to provide different parties having an interest in 
the asset ready access to up-to-date real-time and historical access to the information 
associated with asset usage, maintenance, performance, and the like. For example, besides 
the business using the asset, there is often a third party maintenance organization that helps to 
maintain the asset and a leasing company acting as the true asset owner that leases the asset to 
the business. Because the leasing company lacks appropriate information concerning the 
asset, the leasing arrangement typically takes this lack of information into account as part of 



65678-0037 (5397 DCCSP) 



PATENT 



the lease transaction, often through a combination of both a fixed lease amount tied to the 
asset regardless of use, as well as a financial cushion for the benefit of the true asset o'Wner to 
cover unforeseen problems associated with the asset including over-use and improper 
maintenance. 

In some situations it is known to provide a fixed flat rate rental contract that has a 
variable overtime provision (e.g., an asset owner charges an asset user a flat rate plus an 
overtime charge in excess of a maximum usage level). However, a manual recordation of the 
additional time is required as opposed to automatic recording. 

In other situations it is known to provide billing tied to calendar usage (e.g., monthly). 
However, such usage does not take into account objective usage criteria such as actual hours 
of operation during a fixed time period. 

. However, if the leasing company and the business both had ready access to the same 
information concerning the asset, the leasing company may be willing to share an increased 
portion of the financial risk/reward associated with the asset's usage, maintenance, 
performance, and the like. With appropriate objective information it may be possible to 
distribute a portion of the responsibility to other responsible third parties including the asset 
manufacturer or supplier, and asset maintenance organization. 

It is known to record and store operational parameters or fault codes associated with 
the asset, which may be transmitted using a communications network to a central location for 
the purpose of undertaking diagnostics. It is also known to use handheld devices for the real- 
time sharing of information with a central system. The handheld device can access 
information from the central system such as the status of available inventory. The central 
system can also provide instructions to a user of the handheld device. Finally, it is known to 
use various electronic systems for monitoring inventory. 

However, if each of the entities involved with an asset had ready access to the same 
information concerning the asset, and the ability to update that information as well as related 
information associated with maintenance of the asset on a real-time basis, the involved parties 
may be willing to share an increased portion of the financial risk/reward associated with the 
usage, maintenance, performance, or the like with respect to the asset. With appropriate 
objective information it may be possible to distribute a portion of the responsibility to other 
responsible third parties including the asset manufacturer or supplier, and asset maintenance 
organization. 
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SUMMARY OF THE INVENTION 
This invention relates to a computer ^based system for automatically gathering, 
analyzing, and delivering information relating to the procurement and utilization of a plurality 
of such assets, such as a fleet of industrial equipment, so as to maximize productivity and to 
reduce operating costs and administrative burdens. Each of the assets is preferably provided 
with a data acquisition device for sensing and storing one or more operating characteristics 
associated therewith such as a fault code generated by the asset when there is a maintenance 
problem or when routine, maintenance is required.in accordance with predetermined criteria. 
That information can be transmitted through space to a receiver connected to a local 
controller for storing such information and for transmitting such information over the Internet 
to a remote analysis system. The remote analysis system automatically updates individual 
records associated with each of the assets with the information received from the Internet. In 
response to such information, the remote analysis system automatically analyzes the newly 
provided information and generates reports regarding scheduled maintenance, warranty 
coverage, and other management information. These reports can be transmitted back over the 
Internet to an administrative controller for review by one or more persons responsible for 
managerial review. Additionally or alternatively, the remote analysis system can 
automatically post such reports on a website and, thus, be made available to one or more of 

such persons upon request. 

Not only can the information be provided to an administrative controller, but also it 
can be provided to third parties such as maintenance organizations, asset manufacturers or 
suppliers, and leasing companies. By providing up-to-date real-time and historical 
information concerning the asset, such third parties are willing to share the risk of the asset's 
usage, maintenance, and performance through creative arrangements with the asset user. A 
maintenance organization, for example, may be willing to enter into a fixed maintenance 
contract when it has the ability to readily detect adverse maintenance trends regarding an asset 
and is given the ability to take pro-active steps to address problems before they become 
major. The cost-savings associated with such a pro-active approach by an expert may be 
i S hared to the benefit of the business and the maintenance organization. Similarly, a leasing 
company that can reduce ownership risk through asset monitoring and appropriate asset 
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utilization is more likely to agree to a hybrid minimum term payment and asset usage billing 
system or even a usage based billing system with no minimum payments. 

Various objects and advantages of this invention will become apparent to those skilled 
in the art from the following detailed description of the preferred embodiment, when read in 
light of the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a schematic block diagram of a prior art computer based system for tracking 
and managing a plurality of assets. 

Fig. 2 is a flow chart of a prior art method for tracking and managing assets in 
accordance with the prior art computer based system illustrated in Fig. 1. 

Fig. 3 is a schematic block diagram of a computer-based system for tracking and 
managing a plurality of assets in accordance with this invention. 

Figs. 4 A through 4C are three portions, respectively, of a flow chart of a method for 
tracking and managing assets in accordance with the computer based system illustrated in Fig. 

3. 

Fig. 5 illustrates the relationship of various parties to a database associated with an 

analysis controller. 

Fig. 6 is a flow chart of a subsystem illustrating the analysis of asset-related 
information to determine responsibility for asset utilization, and developing a lease 
relationship between an asset owner and an asset user based on asset utilization criteria. 

Fig. 7 is a flow chart illustrating the providing of maintenance to an asset in further 

detail. 

Fig. 8 is a flow chart illustrating what happens after a work order is generated based 
on maintenance approval. 

Fig. 9 is a flow chart illustrating authorization subsystem 200. 

Fig. 10 illustrates the operation of data acquisition and analysis subsystem 300. 

TYRTATT F. D DESCRIPTION OF THE PREFERRED EMBODIMENT 
Referring now to the drawings, there is illustrated in Fig. 1 a schematic block diagram 
of a prior art computer based system, indicated generally at 10, for tracking and managing a 
plurality of assets, several of which are indicated generally at 11. The assets 11 are illustrated 
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as being a plurality of pieces of movable industrial equipment, such as a plurality of 
conventional forklifts or similar machinery, used in the manufacture of goods in a typical 
factory environment. However, the prior art method could be used to track and manage any 
type of asset 11, such as those described above, used in the manufacture of goods or the 
performance of services. The basic structure and operation of each of the forklifts 1 1 are well 
known in the art and, therefore, require no discussion for a complete understanding of this 
invention. 

The prior art system 10 further included a remote analysis system, indicated generally 
at 12, for tracking and managing the assets 11. The remote analysis system 12 was 
completely separate and apart from the assets 11 and included an analysis controller 13 
having one or more input devices 14 and one or more output devices 15 connected thereto. 
The remote analysis system 12 could be embodied as any conventional electronic controller, 
such as a microprocessor-based computer device. The input device 14 was embodied as a 
keyboard or other conventional mechanism for manually inputting data in electronic form, to 
the analysis controller 13 for processing in the manner described below. The output device 
15 was embodied as a printer or other conventional mechanism for generating a hard copy of . 
the management information generated by the analysis controller 13 in the manner described 
below. 

Referring now to Fig. 2, there is illustrated a flow chart, indicated generally at 20, of a 
prior art method for tracking and managing the assets 11 in accordance with the prior art 
computer based system 10 illustrated in Fig. 1. Throughout this discussion, reference will be 
made to a first person or entity that owns or operates the assets 1 1 that are being tracked and 
to a second person or entity that is responsible for tracking the management information 
relating to such assets 11. Notwithstanding this, it will be appreciated that a single person or 
entity may not only own and operate the assets 11, but also track the management information 
relating thereto. 

In an initial step 21 of the prior art method 20, a record was created for each 
individual asset 11 by the person or entity responsible for tracking such assets, such as one of 
the forklifts 11 illustrated in Fig. 1. This record was created electronically within the analysis 
controller 13 by means of the input device 14 and included a variety of information that was 
desired to be tracked for management purposes. First, the record included information that 
uniquely identified the particular asset 11 being tracked. Such identification information 
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included, for example, data regarding the make, model, year, and serial number of the asset 
1 1, plus any customer-assigned identification number. Second, me record included - 
information that related to the operational characteristics of the particular asset 11 being 
tracked, such as the physical requirements or limitations of the asset 1 1 (mast height, load 
5 capacity, type of tires for the forklift 1 1, for example), the type of fuel used, and the period of 
time or usage between the performance of periodic maintenance. Third, the record included 
information relating to the acquisition of the asset 11 by the owner or lessee thereof. Such 
acquisition information included, for example, the type and date of acquisition (purchase or 
lease, for example), the name of the owner or lessee, the location at which the asset 11 is 
10 used, the expected amount of usage of the asset 1 1 (one, two, or three shifts, for example), 
and the cost of the acquisition or lease. Furthermore, the record included an area for adding 
additional information or remarks as desired. 

In a second step 22 of the prior art method 20, it was determined whether a 
maintenance invoice had been received by the person or entity responsible for tracking the 
15 assets 11 . Typically, a maintenance invoice was a written communication that was generated 
created by or at the request of the person or entity that owned or operated the assets 11. The 
maintenance invoice was usually generated upon the occurrence of an event relating to the 
particular asset 11 and generally contained information regarding the status of one or more 
operational characteristics of that asset 11. For example, after a particular forklift 1 1 had 
20 been operated by the person or entity that owned or operated the asset 11 for a particular 
period of time, it would require the performance of some maintenance. This maintenance 
may, for example, have constituted routine preventative service as a result of the elapse of a 
predetermined period of time or usage. Alternatively, such maintenance may have constituted 
non-routine service, such as a repair of a mechanical breakdown. In either event, a 
25 maintenance invoice was generated as a result of the performance of that maintenance. The 
occurrence of other events related to the assets 11 could also result in the generation of 
maintenance invoices. In many cases, the maintenance was performed by a maintenance 
organization having specialized knowledge of asset 11 and its long-term care. 

Regardless of the nature of the event that caused them to be generated, the 
30 maintenance invoices were generated in hard copy form and contained therein certain 

information that was desired to be tracked for management purposes, such as the date and 
nature of the maintenance that was performed, the amount of usage of the asset 1 1 as of the 
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date of such maintenance, and the cost of such maintenance. To perform the second step 22 
of the prior art method 20, the maintenance invoices were required to be physically delivered 
from the location where the assets 1 1 were being used or serviced to the location of the 
analysis controller 13 or to the location of the input device 14 of the analysis controller 13. 
B y physically delivered, it is meant that the maintenance invoice was transmitted in a non- 
electronic, hard copy form (including, for example, by facsimile) from the person or entity 
that owned or operated the asset 11 (and who performed, or had performed, the maintenance 
on the asset 1 1) to the person' or entity responsible for tracking the assets 11. 

As shown in Fig. 2, the prior art method 20 continuously repeated step 22 until.it was 
determined that a maintenance invoice had been received by the person or entity responsible 
for tracking the assets 11. When that occurred, the prior art method branched from the step 
22 to a step 23, wherein the record contained in the analysis controller 13 relating to the 
particular asset 11 was updated with the information contained in the maintenance invoice. 
This step 23 was accomplished by utilizing the input device 14 to manually enter the 
information contained in the maintenance invoice into the record relating to the particular 
asset 1 1 contained in the analysis controller 13. 

Based upon the updated information contained in the record of the asset 11, the 
analysis controller 13 was programmed to perform a fourth step 24 of the prior art method 20, 
wherein it was determined whether a sufficient period of time or usage had elapsed as to 
trigger the performance of periodic routine maintenance for that asset 11. Typically, such 
determination was made by determining the amount of the elapsed time or usage of the asset 
11 (by comparing the most recent indication of the date or amount of usage of the asset 11 
with the previous date or amount of usage contained in the record stored in the analysis 
controller 13), and by comparing such elapsed time or amount of usage with a predetermined 
standard (also contained in the record of the asset 11 stored in the analysis controller 13). If it 
was determined that a sufficient amount of elapsed time or amount of usage had occurred, the. 
method 20 branched from the step 24 to a step 25, wherein a hard copy maintenance report 
was generated by the output device 15. Then, in step 26 of the prior art method 20, the 
maintenance report generated in the step 25 was physically delivered from the person or entity 
responsible for tracking the asset 11 to the person or entity that owned or operated the asset 
1 1 . The maintenance report advised the person or entity that owned or operated the asset 1 1 
that the time had arrived for the performance of periodic routine maintenance. 
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Thereafter, the prior art method 20 entered a step 27, wherein it was determined 
whether a predetermined period of time had elapsed to generate a periodic management report 
covering some or all of the assets 1 1 being tracked. Alternatively, if in step 24 of the prior art 
method 20, it was determined that a sufficient amount of elapsed time or amount of usage had 
; not yet occurred, the method 20 branched directly from the step 24 to the step 27. In either . 

event, such management reports were typically generated on a monthly basis. Thus, if the end 
of the month had occurred, the prior art method 20 branched from the step 27 to a step 28 
wherein a hard copy management report was generated by the output device 15. Then, in step 
29 of the prior art method 20, the management report generated in the step 28 was physically 
0 delivered from the person or entity responsible for tracking the asset 1 1 to the person or entity 
that owned or operated the asset 11 The management report advised the person or entity that 
owned or operated the asset 11 of the status of some or all of the assets 11 that were being 
tracked, allowing various management oversight and decisions to be made at that time. 
Thereafter, the prior art method 20 returned from the step 29 to the step 22, wherein it was 
15 determined whether a maintenance invoice had been created by or at the request of the person 
or entity that owns or operates the assets . 1 1 and was physically delivered to the person or 
entity responsible for tracking the assets 1 1 . Alternatively, if in step 27 of the prior art 
method 20, it was determined that a predetermined period of time had not yet elapsed to 
generate a periodic management report covering some or all of the assets 11 being tracked, ' 
20 then the method 20 returned directly from the step 27 to the step 22. 

Referring now to Fig. 3, there is illustrated schematic block diagram of a computer 
based system, indicated generally at 30, for tracking and managing a plurality of assets, 
indicated generally at 3 1, in accordance with this invention. As with the prior art system 10 
described above, the illustrated assets 31 are represented as a plurality of pieces of movable 
25 industrial equipment, such as a plurality of conventional forklifts or similar machinery, used 
in the manufacture of goods in a factory environment. However, the method of this invention 
can be used to track and manage any type of asset 31, such as those described above, used in 
the manufacture of goods or the performance of services. 

As above/the basic structure and operation of each of the forklifts 31 are well known 
30 in the art, and, therefore, require no discussion for a complete understanding of this invention. 
However, unlike the forklifts 11 of the prior art system 10, a data acquisition device 32 is 
provided on each of the forklifts 31 for sensing and storing one or more operating 
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characteristics of the associated f orklif 1 3 1 . The basic structure and operation of each of the 
data acquisition devices 32 are conventional" in the art. For example, each of the data • 
acquisition devices 31 may be embodied as an electronic processor or controller that can 
sense or be otherwise responsive to one or more operating conditions of the associated forklift 
31. Each of the data acquisition devices 31 can be responsive to any desired operating 
conditions of the forklift 31 that might be considered important in making effective 
management decisions regarding the operation of the forklift 31. Such desired operating 
conditions can, for example, include the time duration of use (and non-use), distances 
traveled, the extent of fork usage, the nature of hydraulic system utilization, and the like. 
3 More typically for industrial assets, the most importanct criteria is time duration of use. The 
sensed operating conditions of the forklifts 3 1 are preferably stored at least temporarily in a 
memory of the data acquisition device 32 for subsequent communication to a remote analysis 
system, indicated generally at 50, for analysis in the manner described in detail below. Thus, 
the data acquisition devices 32 sense and store the desired operating conditions for each of the 
15 forklifts 31 during use. 

Each of the forklifts 31 is further provided with a transmitter 33 or other 
communications system for transmitting the acquired data from the data acquisition device 32 
to the remote analysis system 50 for analysis. Each of the transmitters 33 may be embodied 
as any conventional device for transmitting the acquired data to the remote analysis system 
20 50, such as a hard-wired communications interface. However, as is well known, each of the 
" * ' forklifts 3 1 is a movable vehicle that is capable of traveling extensively throughout the 

particular environment in which it is used. To facilitate the transmission of the acquired data, 
therefore, the transmitter 33 is preferably embodied as a wireless communications system, 
such as represented by an antenna 34. The transmitters 33 and the wireless communications 
25 systems 34 can be embodied as conventional radio frequency transmitters provided on each of 
the forklifts 31 that transmit electromagnetic signals. However, other well known forms of • 
wireless communication, such as those utilizing light or sound, may be used in lieu of a radio 

frequency transmitter. 

The wireless communications systems 34 are adapted to transmit signals that are 
30 representative of the sensed operating conditions of the forklifts 3 1 through space to a 
receiver 35. In contrast to the forklifts 31 that can travel extensively throughout the 
environment in which they are operated, the receiver 35 is preferably provided at a fixed 
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location within that environment. If desired, a plurality of such receivers 35 may be provided 
at different locations within the environment in which the forklifts 31 areoperated. As the - 
f orklifts 3 1 move about the environment during use, they will occasionally pass by or near the 
receiver 35. When this occurs, the receiver 35 receives the data transmitted from the 
5 respective data acquisition units 32. The receiver 35 is also conventional in the art. 

Preferably, the data acquisition units 32 and the receivers 35 are in bi-directional 
communication with one another. One advantage of such bi-directional communication is 
that the data acquisition unit 32 can send out a query signal on a predetermined basis to be 
received by the receiver 35 when the two units 32. and 35 are sufficiently close to 
10 communicate reliably with one another. Thus, when the data acquisition unit 32 contacts the 
receiver 35, the receiver 35 can send a first signal back to the data acquisition unit 32 to 
instruct it to begin transmitting the acquired data. At the completion of the data transfer, the 
receiver 35 can send a second signal back to the data acquisition unit 32 to acknowledge the 
receipt of the transmitted data. A conventional error checking algorithm can be used to 
15 confirm the accuracy and completeness of the transmitted data and, if necessary, request a re- 
transmission thereof. 

Another advantage of such bi-directional communication is that data in the form of 
new commands, program updates, instructions, and the like can be sent to the data acquisition 
units 32 from the receiver 35. In some instances, such as when a data acquisition unit 32 is in 
20 generally continuous communication with a receiver 35, a user of the forklift 31 can be 
prompted to provide certain information for transmission to the receiver 35 for further 
analysis. 

The receiver 35 is connected to a local controller 36. The local controller 36 is also, 
of itself, conventional in the art and may be embodied as an electronic controller that is 
25 adapted to receive and store at least temporarily the data from each of the receivers 35. 
Alternatively, if the assets 3 1 are fixed in position, such as in the case of a plurality of 
stationary machines used in a manufacturing environment, the receiver 35 or receivers 35 may 
be provided on movable structures that move about the environment to receive the 
information transmitted therefrom. In either event, it is desirable that the local controller 36 
30 acknowledge receipt of the information transmitted from the data acquisition devices 32, 
allowing the data acquisition devices 32 to delete the transmitted information and begin 
storing newly acquired information. A combined system including the data acquisition 
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device 32, the transmitter 33, the wireless communications system 34, the receiver 35, and 
' software for operating the local" controller 36 to gather and report data is commercially- 
available, such as from ID. Systems, Inc. of Hackensack, New Jersey or Requip (formerly 

SXI). 

In a preferred embodiment, the various elements located in an asset 31 are hardwired 
into the electrical system of the asset' to minimize the possibility of undesirable failure or 
tampering. 

Thus, after the forklifts 31 have been operated for a period of time, the local controller 
36 will have gathered and stored therein a certain amount of information regarding the 
individual operating characteristics for each of the forklifts 31. The local controller 36 is 
programmed to periodically transmit the information stored therein to the remote analysis 
system 50 for analysis. This can be accomplished by providing the local controller 36 with a 
conventional modem 37 or other communications device that can convert the stored 
information into a format that is compatible for transmission through an electronic 
communications network, such as the internet 40. As is well known, the Internet 40 is a 
digital electronic communications network that connects computer networks and 
organizational computer facilities around the world.' Access to the Internet 40 can be easily 
obtained in most locations through the local telephone lines or by similar means. 

The system 30 of this invention may be used to track and manage a plurality of assets 
31 located at any desired physical location. Additionally, the system 30 of this invention may 
be used to track and manage assets 31 located at a plurality of different physical locations, as 
suggested by the dotted lines in Fig. 3. Each different physical location can be provided with 
one or more receiver 35, a local controller 36, and a modem 37 to connect the system 30 to 
the Internet 40. 

As mentioned above, the sensed operating conditions of the forklifts 31 are intended 
to be transmitted to the remote analysis system 50 for analysis. Referring again to Fig. 3, it . 
can be seen that the remote analysis system 50 includes an analysis controller 51 that is 
connected to communicate through the internet 40 by means of a modem 52 or similar 
communications device. If desired, a communications server 51a may be connected between 
0 the analysis controller 5 1 and the modem 52. The communications server 5 la is provided to 
selectively receive and organize the information from each of the local controllers 36 for 
delivery to the analysis controller 51. The analysis controller 51 can be embodied as any 
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conventional electronic controller that is capable of receiving the sensed operating conditions 
of the f orklifts 3 1 and for processing that information in a desired manner described in detail 
below. Ideally, the sensed operating conditions of the f orklifts 31 are used to automatically 
generate and analyze management reports relating to the procurement and utilization of a 
plurality of the f orklifts 31 to maximize productivity and to reduce operating costs and 
administrative burdens. An input device 53 and an output device 54, both of which are 
conventional in the art, may be connected to the analysis controller 51. 

As also shown in Fig. 3, one or more administrative controllers 55 (only one is 
illustrated) can be connected to the internet 40 through respective modems 56 or similar 
communications devices. Each of the administrative controllers 55 can also be embodied as 
any conventional electronic controller that can request and receive information from the 
remote analysis system 50 through the Internet 40. In a manner that is described in detail 
below, the administrative controllers 55 are provided to request and receive the management 
information generated by the remote analysis system 50. If desired, the local controller 36 
can also function as an administrative controller 55, although such is not necessary. An input 
device 57 and an output device 58, both of which are conventional in the art, may be 
connected to the administrative controller 55. 

Referring now to Figs. 4A through 4C, there is illustrated a flow chart, indicated 
generally at 60, of a method for tracking and managing the assets 31 in accordance with this 
invention using the computer based system 30 illustrated in Fig. 3. Throughout this 
discussion also, reference will be made to a first person or entity that owns or operates the 
assets 31 that are being tracked and to a second person or entity that is responsible for 
tracking information relating to such assets 31. As above, it will be appreciated that a single 
person or entity may not only own and operate the assets 31, but also track the information 
relating thereto. 

In an initial step 61 of the method 60, a record is created for each individual asset 31 . 
by the person or entity responsible for tracking such assets, such as one of the f orklifts 31 
illustrated in Fig. 3 . The record can be created electronically within the analysis controller 5 1 
by means of the input device 53 and can include a variety of information that is desired to be 
tracked for management purposes, including all of the information described above in 
connection with the forklifts 11 and the analysis controller 13. Additionally, the record can 
further include information regarding the nature and time duration of a warranty provided by 
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the manufacturer or supplier of the assets 31. Such warranty information can be used in the 
manner described in further detail below to automatically determine whether the , 
responsibility for the maintenance being performed on the asset 31 , either in whole or in part, 
should rest with the manufacturer or the supplier of the asset 31 or with the owner or user of 
the asset 31. 

In a second step 62 of the method 60, it is determined whether a maintenance invoice 
has been received by the person or entity responsible for tracking the assets 31. Such 
maintenance invoices can be generated and delivered in the same manner as described above. 
If it is determined that a maintenance invoice has been received by the person or entity 
responsible for tracking the assets 31, the method branches from the step 62 to a step 63, 
wherein the record contained in the analysis controller 51 relating to the particular asset 31 is 
updated with the information contained in the maintenance invoice in the same manner as 
described above. Next, the method enters a step 64 wherein the record contained in the 
analysis controller 51 relating to the particular asset 31 is updated with information from the 
internet 40. Alternatively, if it is determined that a maintenance invoice has not been 
received by the person or entity responsible for tracking the assets 3 1, the method branches 
directly from the step 62 to the step 64. 

As discussed above, the local controller 36 will have gathered and stored therein a 
certain amount of information regarding the individual operating characteristics for each of 
the forklifts 31. The local controller 37 is programmed to periodically transmit the 
information stored therein to the remote analysis system 50 for analysis. The analysis 
controller 51 can include a memory circuit for storing this information from the local 
controller 36. The transmission of the information from the local controller 36 to the analysis 
controller 51 can be performed in real time, upon occurrence of predetermined events (such 
as the gathering of a predetermined amount of information), or at predetermined time 
intervals. In any event, the record contained in the analysis controller 5 1 is automatically 
updated with the latest information regarding the status of the asset 31, without any human 
intervention. 

Based upon the updated information contained in the record of the asset 31, the 
) analysis controller 51 next determines whether a sufficient period of time or usage has 

elapsed as to trigger the performance of periodic routine maintenance for that asset 31. This 
determination can be made in the same manner as described above in connection with 24 of 
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the prior art method 20. If it is determined that a sufficient amount of elapsed time or amount 
of usage had occurred, the method 60 branches from the step 65 to a step 66, wherein an 
electronic maintenance report is generated. If desired, a hard copy of the maintenance report 
can also be generated by an output device 54 connected to the analysis controller 51. Then, in 
5 step 67 of the method 60, the electronic maintenance report generated in the step 66 is 

delivered from the person or entity responsible for tracking the asset 3 1 to the person or entity 
that owns or operates the asset 31 through the Internet 40. As above, the maintenance report 
can advise the person or entity that owns or operates the asset 31 that the time has arrived for 
the performance of periodic routine maintenance. .Moreover, if a specific fault code has been 
10 generated, that can be provided as well. Alternatively, the maintenance report 55 can be 

delivered to a specialized maintenance organization responsible for maintenance of the assets 
31. The electronic maintenance report can, for example, be delivered through the Internet 40 
to one or more of the administrative controllers 55 as desired. Alternatively, or additionally, 
the electronic maintenance report can be delivered through the Internet 40 to one or more of 
15 the local controllers 36. Also, in step 68 of the method 60, the electronic maintenance report 
generated in the step 66 is posted on a website maintained on the Internet 40. The website 
may be maintained either by the person or entity responsible for tracking the asset 31 or by 
the person or entity that owns or operates the asset 31 through the Internet 40. As opposed to 
the direct electronic delivery of the maintenance report to a particular person or group of 
20 persons contemplated in the step 67 , the step 68 contemplates that the maintenance report is 
made available to such person or group of persons at their request over the Internet 40. 

Thereafter, the method 60 enters a step 69, wherein it is determined whether any 
maintenance that has been performed on the asset 31 occurred within the warranty period 
provided by the manufacturer or supplier. Alternatively, if in the step 65 of the method 60, it 
25 was determined that a sufficient amount of elapsed time or amount of usage had not yet 

occurred, the method 60 branches directly from the step 65 to the step 69. In either event, this 
determination can be made by comparing the date of service or amount of usage of the asset 
31 with the warranty information contained in the record for that asset 31 contained in the 
analysis controller 51. If it is determined that service on the asset 31 occurred within the 
30 warranty period, the method 60 branches from the step 69 to a step 70, wherein an electronic 
warranty report is generated. If desired, a hard copy of the warranty report can also be 
generated by the output device 54 connected to the analysis controller 51. Then, in step 71 of 
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the method 60, the electronic warranty report generated in the step 70 is delivered from the 
person or entity responsible for tracking the asset 3 1 to the person or entity that owns or . 
operates the asset 31 through the Internet 40. As above, the warranty report can advise the ■ 
person or entity that owns or operates the asset 31 that the service performed oh the asset 31 
should be paid for by the manufacturer or supplier of the asset 31. The electronic warranty 
report can, for example, be delivered through the Internet 40 to one or more of the 
administrative controllers 55 as desired. Alternatively, or additionally, the electronic 
warranty report can be delivered through the Internet 40 to one or more of the local 
controllers 36. Also, in step 72 of the method 60, .the electronic warranty report generated in 
the step 70 is posted on a website maintained on the Internet 40. The website may be 
maintained either by the person or entity responsible for tracking the asset 3 1 or by the person 
or entity that owns or operates the asset 31 through the Internet 40. As opposed to the direct 
electronic delivery of the warranty report to a particular person or group of persons 
contemplated in the step 71, the step 72 contemplates that the warranty report is made 
available to such person or group of persons at their request over the Internet 40. 

Thereafter, the method 60 enters a step 73, wherein it is determined whether a 
predetermined period of time has elapsed to generate a periodic management report covering 
some or all of the assets 31 being tracked. Alternatively, if in step 69 of the method 60, it was 
determined that a sufficient amount of elapsed time or amount of usage had not yet occurred, 
the method 60 branches directly from the step 69 to the step 73. In either event, such 
management reports are typically generated on a monthly basis. Thus, if the end of the month 
has occurred, the method 60 branches from the step 73 to a step 74, wherein an electronic 
management report is generated. If desired, a hard copy of the management report can also be 
generated by the output device 54 connected to the analysis controller 51. Then, in step 75 of 
the method 60, the electronic management report generated in the step 74 is delivered from 
the person or entity responsible for tracking the asset 31 to the person or entity that owns or 
operates the asset 31 through the Internet 40. As above, the management report can advise 
the person or entity that owns or operates the asset 31 of the same information as the 
management reports discussed above. The electronic management report can, for example, 
be delivered through the Internet 40 to one or more of the administrative controllers 55 as 
desired. Alternatively, or additionally, the electronic management report can be delivered 
through the Internet 40 to one or more of the local controllers 36. Also, in step 76 of the 
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method 60, the electronic warranty report generated in the step 74 is posted on a website 
maintained on the Internet 40. The website, may be maintained either by the -person or entity ^ 
responsible for tracking the asset 3 1 or by the person or entity that owns or operates the asset 
3 1 through the Internet 40. As opposed to the direct electronic delivery of the management 
report to a particular person or group of persons contemplated in the step 75, the step 76 
contemplates that the management report is made available to such person or group of 
persons at their request over the Internet. 

Fig, 4C demonstrates an additional functional aspect of method 60 using the inventive 
system. In addition to determining whether a maintenance invoice has been received, if 
scheduled maintenance has been performed, and determining the party responsibility for 
certain maintenance activities, it is possible to poll asset data points at point 76 from an 
analysis controller database 78 associated with one or more discrete analysis controllers 51 
that may be associated with one or more businesses. A plurality of databases 78 is shown. 
One or more separate databases may be combined to form a logical database 78. When a 
maintenance organization has access to various asset fleets of the same type or make of 
equipment, it may be beneficial to analyze the relevant information using a larger available 
knowledgebase of information to analyze appropriate trends. By analyzing the data points, 
certain maintenance trends can be analyzed and problems can be anticipated before they 
affect asset utilization. For example, if it turns out that asset 31 has a tendency to need new 
batteries after a certain period of usage; the need for such batteries can be anticipated and 
stocked on site when appropriate to facilitate maintenance. As shown in Fig. 4C, once the 
various trends have been analyzed for assets 31, at decision point 80 it is determined whether 
preventative maintenance is required. If it is required, the maintenance is performed as 
shown at point 82 and the information is stored in database 78, The asset data points are then 
25 analyzed again until it is determined that no further preventative maintenance is required. 
Then the system terminates at point 84. Thus, figures 4A through 4C illustrate the use of 
critical information from assets 31 to perform maintenance and to provide a methodology for 
providing access to information by various third parties. 

There are a number of significant advantages to having appropriate access to and the 
30 ability to analyze data associated with an asset 31 and the interaction of various parties with 
that asset. Fig. 5 illustrates the beneficial interrelationships that promote efficiency by having 
the various parties associated in some way with an asset 31 in one or two-way communication 
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with analysis controller 51 either by way of administrative controller 55, reports 71 or 75, 
web site postings electronic mail, or the like. -As illustrated, a maintenance organization 86, 
an asset manufacturer or supplier 88, asset user/business 90, and asset owner/leasing company 
92 all at least provide information to analysis controller database 78 of analysis controller 51. 
Both an individual user 85 and the asset 31 itself also provide data as illustrated in the figure 
and discussed herein. Therefore, at the very least each party is required to contribute pertinent 
information concerning its interaction with an asset 31 to database 78 of asset controller 51, 
where the information is available for further consideration and analysis. 

As already discussed above, asset 31 provides usage and performance data that is 
stored in asset controller 51 according to certain predetermined criteria important for that 
asset including such things as asset location, model, age, usage, and maintenance status. 
Once relevant data is collected, it is possible to analyze utilization of a specific asset 3L It is 
also possible to analyze a class of assets 3 1 using one or more types of available data. From 
such an analysis, best mode practices can be developed with respect to asset utilization 
including preventative maintenance and a determination of the extent of optimum asset use. 
More specifically, for example, a business 90 may decide to standardize its fleet of assets, 
replace specific assets that have demonstrated unreliability, and either upsize or downsize a 
fleet to maximize safe asset utilization. 

As discussed in greater detail with respect to Fig. 9 below, utilization of asset 31 by an 
individual user 85 is also tracked. A review of the available data can also provide detailed 
information on the interaction of a business 90 or individual users 85 with assets 31 as 
opposed to other businesses or users. From such an analysis it is possible to consider training 
issues, certification, and issues related to particular individuals, whose actions can have 
significantly influence asset utilization. 

The role of other vendors such as part distributors, an example of another vendor 93, 
and maintenance organizations 86 can be compared with respect to other parties in similar 
roles or historical data to determine their effectiveness, While business 90 may provide its 
own maintenance of assets 31, a separate maintenance organization 86 is in the illustrated 
embodiment. 

A vendor may be penalized or rewarded depending on the results of its activities, 
providing increased incentives to promote efficiencies. With respect to asset manufacturers or 
suppliers 88, it is possible to compare assets provided by different parties 88 to determine 
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how well their assets perform in practice. Thus, warranty issues, maintenance costs, lost 
operation time, and the like can be determined from an analysis of asset information over 
time or involving different manufacturers to provide guidance on how assets 31 from a 
particular manufacturer perform in different environments and as compared to competing 
assets of other manufacturers or suppliers in that environment. 

More specifically, for an asset manufacturer or supplier 88, warranty information as 
shown by steps 70 through 72 of Fig. 4B is of particular interest. While it may not be 
appropriate for a supplier 88 to be able to alter information in database 78, the ability to 
quickly and accurately collect information concerning warranty obligations and the like is of 
particular benefit to all of the parties. For example, warranty issues may be caught more 
quickly, ultimately reducing asset cost and operation while simultaneously promoting asset up 
time. 

The advantages of an asset owner 92 having at least one and possibly two-way access 
to the real-time and historical information stored in analysis controller database 78 as well as 
the ability to communicate with supplier 88, maintenance 86, and business 90, is illustrated in 
subsystem 98 illustrated in Fig; 6. It is assumed for the discussion that follows that the 
owner of the asset 31 is a separate asset owner 92 such as a leasing company, as opposed to 
business 90 itself, although this is not a requirement of the invention, subsystem 98 is often 
activated by the asset owner 92 using data from database 78, but typically utilizing its own 
lease administration and billing systems. In many cases it is also using its own fleet analysis 
and management systems, which are typically aggregating information from a number of 
different fleets associated with a plurality of businesses 90. These various systems, one or 
more of which may be used independently or in concert, are collectively shown at point 99. 
As noted above, web-site access, generated reports, analysis controllers 51, and 
administrative controllers 55 provide exemplary access points for pulling asset information 
from system 30. 

An asset owner 92 and an asset user such as business 90 share the common interest in 
maximizing efficiency by taking into account such variables as asset usage and asset costs. 
The more information that is available, the more likely that efficiency is maximized. In 
traditional leasing relationships involving non-fixed or movable assets such as forklifts where 
minimal asset utilization information is available, the burden of determining the point of 
maximum efficiency typically rests with business 90, since it has control over the asset. 
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Therefore, a leasing company 92 typically enters into a lease arrangement where a fixed lease 
amount is paid in periodic payments by business 90 over the life of the lease. At best; only 
minor flexibilities are provided. When leasing company 92 regains control of an asset 31 at 
the end of the lease term, there is uncertainty concerning the condition of the asset. This .- 
5 uncertainty also typically rests with business 90 in the form of a financial cushion 
incorporated into the leasing relationship. 

However, such uncertainty is minimized in the present invention. As shown at point 
100, asset owner 92 is able to analyze the various desired objectively generated asset data 
points associated with an asset 31. As noted above, these data points can include the time of 
10 asset usage within a fixed time period, distance traveled, and certain performance parameters 
associated with the particular asset (e.g., hydraulic system usage or fork usage for fork lifts). 
As noted above, in practice, for industrial assets the time of use is the most important single 
data point. Then, as shown at point 102, asset owner 92 may analyze maintenance 
considerations. For example, a major routine overhaul as compared to a system failure can be 
15 analyzed. Then at point 104, the asset owner 92 can compare the raw data from the asset with 
maintenance conducted during the same time period. By comparing the raw data with - 
maintenance considerations, the owner is able to analyze the asset utilization under the 
control of business 90 if maintenance organization 86 and supplier 88 are different third 
parties. For example, the asset owner 92 can determine that an asset 31 has been used very 
20 little during the time period, even allowing for maintenance. Alternatively, the owner may 
determine that the asset is being used continuously when not undergoing maintenance, • 
possibly suggesting that additional assets may be appropriate to reduce overall maintenance 
stress on the pre-existing asset. 

Additional information can be analyzed by the asset owner as shown at decision point 
25 106. Typically, the information includes data associated with other parties having access to 
database 78. As shown at point 108, for example, the asset owner 92 can evaluate the 
maintenance relationship with maintenance organization 86. If the relationship has been very 
positive, an appropriate incentive may be provided to the organization in the form of shared 
cost savings. Alternatively, if the relationship has been negative, an appropriate penalty may 
30 also be implemented. The same considerations are available if business 90 acts as its own 
maintenance organization 86. 
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Similarly, the' asset owner 92 may evaluate its relationship with the asset supplier 88 
as shown at point 1 10. The information may affect asset payments from the owner to The 
supplier or the futurerelationship of the parties. 

Afurther evaluation, shown at point 111, may include an analysis of individual users- 
5 85 themselves associated with a specific business 90 and their interaction with particular 
assets 31 or classes of assets, and such things as training level, certification, accident rates, 
and the like as discussed with respect to Fig. 9 and authentication subsystem 200 below. 

One of the key advantages of the present invention is the ability to take data 
concerning any asset 31 and the interaction with that asset by any party, including user 85, 
10 maintenance organization 86, asset manufacturer or supplier 86, business 90, asset owner 92, 
or other parties/ vendors 93. Moreover, groups of assets may be combined. Thus, it is 
possible to analyze data to identify the cost of owning or using any asset 31 and the 
productivity of that asset. Moreover, based on an adequately large statistical universe of data 
it is possible to benchmark asset utilization and cost against others in similar circumstances to 
15 identify best practices. Thus, it is possible to efficiency can be maximized while 

simultaneously minimizing unwanted waste by identifying time and cost saving opportunities. 
It is also possible to determine those parties providing best practice services with respect to 
asset utilization (e.g., maintenance) so that their services can be expanded and appropriate 
recognition given for their efforts. Alternatively, it is possible to identify parties providing 
20 unacceptable services so that appropriate remedial action, may be taken (e.g. , a user 85 has 
inadequate training to properly use an asset so additional training needs to be provided). 

In practice, the present invention provides a business 90 with a report screen showing 
information regarding the fleet associated with that business. Business 90 compares its 
current fleet information with its own historical information or pertinent information from 
25 unnamed companies in the same general industry. A side-by-side comparison will be 

provided, thereby providing a business 90 or the asset owner 92 with guidance on how to 
improve fleet utilization using the best practices comparison. 

These various advantages are applicable even if asset owner 92 and business 90 are 
the same entity. However, more typically with industrial equipment, asset owner 92 is 
30 different than asset user 90, wherethe two parties have entered into a lessor/lessee 
relationship. In such a case, the information in database 78 may be used to mutually 
maximize the relationship between the asset owner 92 and the business 90. With appropriate 



-21- 



65678-0037 (5397 DCCSP) PATENT 

safeguards asset owner 92 may be willing to share in a greater portion of the risk associated 
- with the utilization of asset 31 in. determining a lease rate based on an analysis of each: user ; . .. 
fleet or individual asset as shown at point 1 12. Most significantly, rather than eutering into a 
traditional fixed lease amount as noted above, asset owner 92 may be willing to enter into a 
5 hybrid lease arrangement wherein the lease charge may be a combination of one or more of 
the following elements: 1) a minimum payment that has to be made if asset utilization is 
below a pre-determined minimum threshold; 2) a usage based-payment that is made if usage 
is above the pre-determined minimum threshold and below a pre-determined maximum 
threshold; 3) a penalty payment or surcharge is made if utilization is higher than the pre- 
10 determined maximum threshold; and 4) payments/rewards based on incentive issues such as 
asset re-allocation or timely maintenance. 

The decision of whether to use usage-based billing based on one or more objective 
criteria based on an analysis of asset utilization is shown at decision point 114. The decisions 
to charge either a minimum payment if a certain usage level is not met, or to charge a usage 
15 penalty above a maximum appropriate usage level, are shown by decision points 116 and 118 
respectively. Thus, a variable-amount lease may be developed based on an analysis of 
objective criteria that is based in large part on the actual portion of an asset's life that is 
consumed by the asset user (e.g., usage hours). In a preferred embodiment, the analysis is 
based on a pre-determined usage/pricing matrix in combination with actual usage for a 
20 specified time period. Once a level of maximum efficiency has developed, leasing will 
typically be primarily, if not solely, based on asset usage billing. 

Through the use of the innovative leasing arrangement based on improved information 
availability to asset owner 92, the expenses of an asset user such as business 90 can be more 
accurately aligned with usage and asset value consumption. More operational flexibility is 
25 provided to business 90. When leasing is based predominantly on asset usage billing, a 

business 90 is able to adopt true off-balance sheet financing (i.e., the business is not required • 
to note a financial obligation even in the footnotes of various financial reports as opposed to 
standard off-balance sheet leasing where a company must disclose the lease in footnotes even 
if the lease does not show up on the balance sheet). At the same time, asset owner 92, can 
30 collect information from a variety of sources to maximize its relationships with its own 

vendors and customers to the benefit of all related parties by minimizing inefficiencies and 
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providing appropriate accountability with maximum accuracy and validity tied to a minimal 
likelihood for mistakes, misinformation, or even fraud. " 

These various factors can be adjusted dynamically by the asset owner 92 as a 
knowledge base is collected within its internal systems 99 and based on the actions of the 
other related parties. For a sophisticated asset owner with numerous fleets, it can conduct 
appropriate analyses over all of its fleets to determine certain trends, which it may 
advantageously use. 

For example, if supplier 88 or maintenance organization 86 is responsible for 
abnormally low asset utilization as opposed to actions within the control of business 90, then 
the risk associated with these possibilities can be shared between asset owner 92 and various 
affected businesses 90 and transferred in some fashion to the responsible party. Thus, in a 
more preferred embodiment of the invention, asset usage is adjusted for maintenance 
considerations if business 90 is not responsible for its own maintenance. 

As shown at point 120, once the readily available information is analyzed in view of 
the business relationship between an asset owner 92 and a business 90, an invoice and billing 
module associated with the asset owner's own internal systems 99 is invoked that generates 
an appropriate invoice that is sent by the asset owner to the business for payment and 
subsystem 98 terminates at point 122. In a preferred embodiment, once subsystem 98 is 
developed for a particular situation, and in the absence of an extraordinary event, invoicing is 
automated based strictly on the objective criteria developed with minimal outside 
involvement. 

A key advantage of the present invention is that real-time data is collected by data 
acquisition device 34 and timely transmitted to local controller 36 for transmission to 
database 78 of analysis controller 51 . If incomplete or limited data representing only a small 
portion of the appropriate asset data points are transmitted, then appropriate decisions cannot 
be made to maximize asset utilization. For example, in the case of forklifts, both time of 
usage and distance traveled help provide information concerning asset utilization and 
maintenance considerations. 

Thus, the computer based system 30, including subsystem 98, of the present invention 
provides a superior method for tracking and managing the assets 31 than the prior art system 
10. First, by providing the assets with the data acquisition devices 32 and the 
communications system 33 and 34, the operational characteristics and other information 
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regarding the assets 31 is automatically sensed and transmitted to the analysis controller 51 on 
a real time basis, without requiring human intervention. or assistance.. Second, the analysis 
controller 51 is programmed to analyze such information as it is received and to automatically 
generate maintenance and warranty reports in response thereto. Third, all of the reports 
generated by the analysis controller 51 are automatically delivered to the appropriate persons 
through the Internet 40, either directly to one or more of the administrative controllers 55 or 
by posting on a web site, electronic mail or similar mechanisms. Fourth, as shown by 
subsystem 98, the information can be used to maximize asset usage efficiency. As a result, 
the computer based system 30 facilitates the gathering, analyzing, and delivering of 
information relating to the procurement and utilization of the assets 31 so as to maximize 
productivity and to reduce operating costs and administrative burdens to the benefit of all 
parties having a relationship with the asset and an interest in its performance. 

The providing of maintenance to an asset 31 is illustrated in further detail in Fig. 7. In 
addition to determining whether it is necessary to provide scheduled maintenance as noted at 
step 65 of Fig. 4A, changes in operational parameters associated with asset 31 as shown at 
point 150 may result in the generation of a specific fault code if a maintenance problem is 
detected that requires a more expeditious response. The fault code may be generated by the 
asset itself using one or more sensors associated with operational parameters of asset 31 as 
shown by point 152 and communicated to the data acquisition device 32. In addition, 
analysis controller 51 may analyze the raw operational data received from the asset 31 and 
compare it with analysis controller database 78 including the history of the specific asset 31 
as well as the history of similar assets from which maintenance trends may be determined as 
discussed with respect to Fig. 4C above. Based on an analysis of such trends, proactive 
lower cost maintenance can be timely performed that results in the avoidance of higher cost 
maintenance at a later date, which happens in the absence of real-time information available 
for review and analysis. 

A fault code may even be generated based on the actions of the asset operator. In a 
preferred embodiment of the invention, an electronic checklist 154 is completed by the asset 
operator on a regular basis, which may include information concerning asset performance that 
is more detailed than that available from a review of raw operational parameters. In 
accordance with OSHA requirements, for example, at the end of each shift, a forklift operator 
must complete a checklist concerning the performance of the asset during the shift. Some of 
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the questions associated with checklist 154 are directed to maintenance issues. Therefore, in 
a preferred embodiment of the invention, checklist 154 would be. completed electronically at 
the asset 31, and transmitted by way of the data acquisition device 32 to analysis controller 51 
as discussed above. The information would be analyzed to determine if an OSHA/repair need 
is identified. Preferably, the analysis is automated in accordance with a comparison of the 
operational status with pre-determined rules. For example, if a question asks if there is a 
hydraulic leak for a forklift and the answer is "yes", then maintenance would be appropriate. 

Once it is determined that maintenance of some type is required as shown at point 156 
based on an analysis of the operational status of asset 31, a maintenance report 66 is 
generated as also shown in Fig. 4 A and made available electronically at point 67' such as by 
the Internet or by posting on a website as also shown in Fig: 4A. The use of electronic mail, 
or the providing of real-time access to the raw data stored within database 78 by the 
maintenance organization 86, shown in Fig. 5, is also possible to generate the maintenance 
report 66. An advantage of providing a maintenance organization 86 real-time access to the 
raw data representing the operational status of asset 31 is that it may develop specialized 
analysis tools based on its own expertise in maintenance, resulting for example in the creation 
of specialized rules for use in automatically analyzing raw data in determining whether 
maintenance is required, minimizing the need for manual review and determination. 

In a preferred embodiment, the priority of the proposed maintenance required 158 is 
noted on the maintenance report. For example, critical maintenance issues should take 
precedence over routine issues. Moreover, the system generally institutes an approval process 
as shown at point 160. For example, if the proposed maintenance is related to warranty work 
such as noted with respect to step 69 of Fig. 4B, the manufacturer or supplier should approve 
the maintenance. If a lessee is responsible for the proposed maintenance, it should approve 
the maintenance before it is performed. In some cases, the maintenance organization 86 itself 
approves the maintenance, such as when it has a contract that involves pre-payment of 
particular maintenance. Finally, as shown at point 162, in some cases it may be desirable to 
have the lessor or owner of the asset have the ability to review and override any refusals to 
perform maintenance since it has the ultimate responsibility for asset 31. If no approvals are 
given, the process is terminated at point 164. A review of any automated rules that generated 
a request for maintenance approval may also be appropriate. When maintenance approval is 
rejected, any automated rules that generated the original maintenance request can be fine- 
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tuned by including the results of the approval process. Over time, almost all maintenance 
requests should be generally approved. Information regarding approval is stored in database 
78. 

For preventative maintenance, it is expected that pre-approval will generally be 
granted by the necessary parties based on prior agreement as to the nature and timing of such 
maintenance. 

Once maintenance has been approved, a work order 166 is generated. As shown in 
Fig. 8, work order 166 is sent electronically to appropriate maintenance personnel that 
contains all of the critical operating data required to effectively schedule and carry out the 
maintenance. Typically, for example, the data includes hour meter reading, any fault codes, 
asset identification criteria, operator of record, contact information, and asset location. 
Moreover, based on information contained within the fault code or retrieved from the 
knowledgebase, information concerning anticipated parts may also be provided as well as the 
nearest location from where they may be retrieved (e.g., at a customer location, or from a 
local servicing dealer). Finally, the work order 166 preferably contains the past recent history 
of the particular asset 31 so that the mechanic can use this information to expedite 
maintenance. 

In a preferred embodiment of the invention, the work order 166 is transmitted 
electronically to a handheld device 168 associated with specific maintenance personnel 
assigned to carry out the maintenance. Device 168 includes an appropriate graphical user 
interface (GUI) that permits the receiving and transmitting of both alphanumeric and 
graphical based information. Examples of hand held devices include a variety of systems 
produced that use either the Palm® operating system from Palm, Inc. or a sub-set of 
Microsoft® Windows® from Microsoft Inc. Moreover, in a more preferred embodiment of the 
invention, the hand held device 168 is in real-time two-way communication with analysis 
controller database 78. Thus, under appropriate circumstances the handheld device 168 can 
access such things as dealer billing systems, inventory listings, customer work order approval 
records, and fleet management information. Rather than having the work order include the 
past recent history of the asset 31 to be serviced, it is possible to use the two-way 
communication link to request the necessary history when advantageous to do so. 

Once the maintenance is completed, handheld device 168 is used to update database 
78 as shown at point 170, including labor information and an identification of any parts 
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required to effect a repair. If not already clear based on the contents of database 78, the 
inventory location from which, any parts were pulled should also be t provided. Ideally, "the 
information is transmitted on a real-time basis from the handheld device 168. Alternatively, 
however, the information can be transmitted upon routine synchronization of the handheld 
5 device with database 78. It is also possible to manually enter the information into the 
database 78. 

The maintenance information is passed to database 78 where it may be used to 
generate maintenance tracking reports 172, and comprehensive invoices 174 listing both labor 
and part costs. Since the information is integrated. with pre-existing asset information, no re- 
10 keying is required. Moreover, as noted above with respect to Fig. 4C, the complete 

maintenance history of a particular asset or class of assets may be reviewed and analyzed in 
detail for specific trends of interest. 

In addition, when parts are used, as shown at point 176, system 30 preferably permits 
comparison of the parts used with existing inventory for the specified parts storage location. 
15 Based on maintenance trends associated with a class of assets 3 1 or a specific asset 31, it is 
possible for the system to automatically order replacement parts for an inventory location if 
the number of parts in a particular inventory fall below a pre-determined threshold as shown 
at points 178 and 180. The threshold is calculated at least in part based on an analysis of the 
prior maintenance of both the asset 31 and the class of assets associated with the asset. Other 
20 factors may include the age of the class of assets, the time of the year, usage trends and the 
like. As one example, in the winter different parts may be required as opposed to in the 
summer. As another example, more tires may be required for a forklift asset if a number of 
the assets are reaching a preventative maintenance stage where tires have to be replaced. The. 
system terminates at point 182. 
25 It is also possible to provide online copies of parts catalogs including part numbers 

and exploded views of parts, including to hand held device 168. In some cases a comparison 
table of equivalent parts may be provided to reduce part acquisition timing or cost. 
Moreover, system 30 preferably keeps track of part availability and cost throughout a parts 
availability network. Thus, no one party is required to keep as many items in stock since 
30 ready access to items stored at a different location is possible. Transaction costs in locating 
and requesting items from different locations is minimized since the information is readily 
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stored and accessible from system 30. Item stock reduction at any one location is also 
possible for the reasons discussed above where careful quantity controls are implemented. 

Under some circumstances it may even make sense to have a central parts depository 
with inventory actually held and controlled by a third party such as a courier service. For 
example, the courier service can ship parts as needed to effect a repair or replenish a reduced 
inventory at a remote location. With a central depository, the cost of maintaining the 
inventory can be borne by the party having the best ability to do so. For example, if an asset 
owner 92 has many businesses 90 using a class of assets 3 1, it may be able to provide 
economies of scale to the businesses by being responsible for ordering and stocking inventory 
parts for use by all affected businesses. Non-related businesses may also be provided access 
to a part inventory at a higher cost, giving them a further incentive to actively participate in 
system 30 to enjoy improved economies of scale. Thus, system 30 provides enhanced 
customer service through reduced cost and a more efficient part access and ordering process. 

Inventive system 30 provides a number of additional advantages for maintenance. For 
example, through the use of electronic information transmission and analysis, maintenance 
information is transferred and available real-time for review and for the initiation of necessary 
actions such as approval, the tracking of performed maintenance, the ordering of replacement 
parts to replenish depleted inventories, and automatic invoice generation. Since asset 31 
communicates its own maintenance needs in consultation with an appropriate knowledgebase 
associated with database 78, human intervention is minimized. As more information is 
gathered over time, the scheduling of preventative maintenance can be optimized to eliminate 
either too little or too much maintenance. Further, system 30 automates a very paper- 
intensive and time cumbersome process by permitting direct communication with the various 
information elements associated with an asset 31. As a result, the flow of data is more 
effectively controlled, dispersed, routed, monitored, and acted upon. In practice, the number 
of people involved in the maintenance process can often be reduced while the speed of 
providing maintenance can be increased. Thus, potential downtime and related performance 
issues can be more timely addressed. 

A further aspect of the invention, authorization subsystem 200 within system 30, is 
illustrated in Fig. 9. Authentication to access an asset 31 is tied to pre-determined rules. 
Specifically, authorization subsystem 200 keeps track of all individual users 85 using an asset 
31. It prevents asset utilization by uncertified users 85. System 30 may require that a user 85 
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be trained or certified to utilize certain assets 31. Even if trained or certified, system 30 may 
only allow a user 85 to access an asset 31 for a limited period of time within a pre-set time . 
range (e.g., OSHA or other work regulations may only permit access for ten (10) hours within 
every twenty-four (24) hours). Further, authentication may be denied if a user : 85 is found to 
have too many accidents. By tracking regulation requirements, training or certification issues 
and even accident rates, an asset 31 is more likely to be well maintained and well utilized. As 
a result, there are reduced operating costs, minimized potential fines through enhanced 
regulation compliance, and prolonged asset life through appropriate usage. 

Apart from user 85, maintenance considerations may make an asset 31 unavailable. If 
critical maintenance is required, the unavailability of an asset 31 may prevent unwanted 
problems resulting from inappropriate continued use, again reducing operating costs and 
extending asset life. 

In other situations, authorization subsystem 200 is essentially a beneficial subscription 
service. For example, a single asset 31may be available to different users at pre-set times 
based on a reservation system, which is tracked through authentication subsystem 200. A 
prior reservation may take precedence over a desire to use an asset without such a reservation. 
Alternatively, access to an asset 31 may be terminated if payments to a third party such as 
maintenance organization 86, asset supplier 88 or asset owner 92 are in arrears. Of particular 
benefit, even when authorizing access, the ability to track usage with respect to a particular 
user 85 permits different monetary or time-based asset access rates depending on the specific 
user or, entity associated with that user. 

As shown at point 201, a record of user 85 is created that may be stored in analysis 
controller database 78. The information associated with user 85 preferably includes such data 
as a unique user code, user identification information (e.g., employer, location, address, and 
contact information) the number/class of assets for which the user is permitted access, safety 
record (e.g., number of accidents associated with each asset and over what period of total 
usage or time), and training or certification records. 

A user attempts to access a particular asset at point 202. The access may be through 
the use of an access device 204 associated with the particular user (e.g., access card, magnetic 
key, or key pad code) and a corresponding approval device 206 associated with an asset 31 
that is connected to data acquisition device 32 for. authorization confirmation. In turn, as 
noted above, data acquisition device 32 is associated with transmitter 33, which is in selective 
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communication with local controller 36. As shown at point 208, when a user attempts to 
access asset 31 for use, an attempt is firsfmade to access remote system 50 for authorization. . 
If communication is not possible, an attempt is next made to communicate with local 
controller 36 at decision point 210, which preferably includes a data cache for at least a sub- 
set of users 85 associated with a particular facility where an asset 31 is located. The data 
associated with local controller 36 may not be as up to date as that available from direct 
access to analysis controller database 78. In turn, if communication is not possible even with 
the local controller, an asset cache of data 212 associated with a particular asset 31 may 
optionally be available for access by approval device 206, as shown at decision point 214. 
Once again, the data may not be as up to date. On the other hand, at times, the data cached 
within asset cache 212 or local controller 36 may be more up to date than that associated with 
system 50. The appropriate data is communicated between asset cache 212 and local 
controller 36, and then between local controller 36 and system 50, as communication between 
the appropriate devices takes place. 

Once data related to asset 31 and user 85 is located, system 30 determines if user 85 is 
an authorized user for asset 31 at decision point 216, or if the asset 31 itself is available for 
user at decision point 218 in accordance with pre-determined rules or considerations such as 
those noted above. If authorization is not granted, a communication interface 220 associated 
with asset 31 preferably gives the reason for the denial and the steps required to obtain 
20 authorization 222. It may even be possible to use communication interface 220 to provide 
interactive training and certification under some circumstances. As suggested above, a 
communication interface 220 may even be used to complete an interactive asset checklist as 
discussed above before and after asset operation by each user 85. Finally, even if approval is 
given, confirmation as well as special instructions or information of importance to user 85, 
25 collected at point 224 (e.g., remaining access time, timing for re-training or re-certification, or 
next scheduled maintenance) may be displayed to the user. 

Finally, if a user 85 is not authorized, either because of communication problems or 
issues associated with either the user or the asset itself, preferably some type of supervisory 
override, such as a master access device or code and shown at decision point 226, may be 
30 selectively implemented between devices 204 and 206 to permit asset utilization. Even if 
there is such an override, however, information associated with asset utilization is still 
recorded and communicated as taught above. 
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Finally, any pertinent authentication subsystem data is stored in database 78. 
Moreover, pre-determined rules may be established that provide automatic instructions. to 
system 30 when such authentication subsystem data should be communicated to a third party 
such as a supervisor, trainer, or security personnel as a result of a user attempting to access an 
asset 3 1 as shown at point 230. For example, if a user 85 needs to have additional training, 
that information needs to be communicated to the appropriate party (e.g., supervisor and 
trainer). Training may take place using internal personnel or it may be outsourced to a 
vendor 93 (shown in Fig. 5) in a manner similar to maintenance, as discussed above. System 
30 makes it possible to schedule training and even track the cost and corresponding benefits 
of training through access to real-time and historical asset or user data not generally available 
except in accordance with the teachings of the present invention. As another example, if 
unauthorized personnel attempt to use an asset 31, it may be appropriate to send an urgent 
message to appropriate security personnel at the location of asset 31. Finally, authentication 
subsystem 200 terminates at end point 232, 

As shown most succinctly in Fig. 5, numerous parties have access to analysis 
controller database, which stores data with respect to asset 31 and various parties having a 
relationship to that asset. The collected data may be used or analyzed in any one of a number 
of different ways depending on the interests of the party. For example, a maintenance 
organization is interested in using the data available to improve maintenance and reduce 
associated costs; asset supplier 88 desires to examine and minimize warranty issues; and asset 
owner/leasing company 92 desires to appropriately maximize its return on investment, a 
desire shared with each business 90. From the perspective of an individual user 85, such 
issues as appropriate training and certification have also been discussed. 

"What if inquiries are particularly important to successful implementation of system 
30. For example, when proposing the use of system 30 to a party such as a potential 
customer, the ability to analyze historical data and performance with respect to similarly 
situated customers is invaluable to provide a breakdown of costs and possible cost savings. 
As noted above, with appropriate information, an asset owner 92, such as a leasing company, 
may be able to share in part of the risk of asset utilization with appropriate data access and 
control 

To facilitate these types of analyses, it is important to have robust access to analysis 
controller database 78, which can actually be one or more databases of information tied 
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together so as to be accessible for the purpose of an analysis of system 30. In a preferred 
embodiment, hand held device 168 or a similar type of computing device provides a desirable 
access point to database 78. 

However, before the parties can take advantage of system 30, it is essential to create a 
•foundational base of information that provides a framework for further analysis. Ideally, pro- 
created forms or templates help facilitate data collection and analysis. For example, when 
talking to a potential customer, it would be helpful to have access to cross-reference materials 
related to competitor assets, lease pricing rate factors, historical data and the like. Certain 
query forms can be used to collect relevant raw data and other query forms can be used to 
retrieve useful data based on a consideration of the raw data to provide the basis for 
recommended courses of conduct to promote safe utilization and efficiency while reducing 
costs. Thus, the actual analysis typically takes place at a central location having the 
appropriate computational resources with the results preferably being transmitted to hand held 
device 168. Under some circumstances, an analysis is possible directly on-site using the data 
collected and analyzed without direct access to database 78 based on a sub-set of data and 
logic protocols in the form of analysis tools stored on hand held device 168. 

Even when not in real-time contact with database 78, hand held device 168 is often 
invaluable. It permits the automation of survey data entry by an account manager so that 
• information concerning assets 31, a business 90, individual users 85, and other related parties 
may be entered on-site and later transferred to database 78. The use of paper forms, and 
manual translation of information is eliminated, speeding up data entry. For example, injhe 
past an account manager might have handled more than twenty (20) data sheets that tracked 
specifications of the current fleet of assets 3 1 for a new customer business 90. The data 
sheets were taken back to the office and manually entered into a local database. 
Simultaneously, an intermediate source of error related to manual keying or a similar 
translation method is eliminated. 

A data acquisition and analysis subsystem 300 is illustrated in Fig. 10. Subsystem 
300 facilitates the collection of raw fleet survey data 302 upon initiation of system 30 by a 
party so that a baseline level of data may be provided to system 30 for consideration and 
analysis. An account manager 304 collects raw data with respect to each affected asset 31 
and all parties having interaction with the asset such as the parties identified with respect to 
Fig. 5 above. Of course, other parties may also contribute fleet survey data if they have 
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interaction with an asset 3 1. The data is preferably inputted into a handheld device 168 using 
pre-defined forms 306, transmitted to a desktop computer 308, and. then ultimately stored in 
analysis controller database 78. To help with analysis of particular data, the process may be 
reversed, with data pulled from database 78 to desktop computer 308, transmitted to hand 
held device 168, and used by account manager 304 to perform a desired analysis for any 
affected party. 

Preferably, hand held device 168 uses an operating system 312 provided by Palm, Inc. 
A forms manager 314 from Puma Technologies, Inc. known as the Satellite Forms software 
development package is used to generate data forms 306, which are used to enter the required 
information or display stored data from hand held 168 or from analysis controller database 
78. When collecting raw data, account manager 304 follows inquiries associated with form 
306 to enter required information. In contrast to manual methods, it is preferably possible to 
advise when inappropriate data is entered or if a field is missed. Thus, any data entry errors 
can be addressed on the spot when the source of the original data is readily available. Hand 
held device 168 stores locally collected data 316 such as fleet survey data 302, may include 
retrieved data 318 from database 78, and a number of different analysis tools 320 for 
evaluating the stored data. For example, one analysis tool 320 may use a set of rules to 
estimate the total life of an asset under the circumstances currently in place at a business 90 
and compare them to known "best practices" for the same asset along with proposed process 
changes to increase asset life to reach the "best practices" level. 

Preferably, computer 308 includes an operating system 322 provided by Microsoft 
such as Windows® 98, Windows® Millenium or Windows® 2000. It has a plug-in 324 
provided by the party responsible for hand held operating system 3 12 to provide a 
synchronization conduit 326. Synchronization is handled through a conventional or USB 
serial data port on the desktop computer 308 and a cradle hardware device 328 associated 
with device 168. During use of synchronization conduit 326, data values and associated data . 
stored on-hand held device 168 and desktop computer 308 are interchanged in accordance 
with parameters provided in forms manager 314 and a corresponding forms manager 
computer plug-in 330 on desktop computer 308. Desktop computer includes data from hand 
held device 168, data from database 78 to either be used locally by the computer or 
transferred to hand held device 168, data received from device 168 or manipulated locally 



-33- 



I 



65678-0037 (5397 DCCSP) PATENT 

using one or more analysis tools 332, and data to be transmitted to database 78 for long-term 
manipulation or storage. - • . ^ 

For example, when using subsystem 300 to transfer fleet survey data 302 that has been 
placed into hand held device 168 as locally collected data 316. The data transmitted includes 

5 both data elements and lists of value fields identifying a data source and the specific data 
values populating each data element. The data is then transferred to database 78 from 
desktop 308 in accordance with pre-determined rules. Preferably, the data is associated with 
fixed fields that are consistently defined between hand held device 168 and database 78 so 
. that the data merely populates the appropriate fields within database 78 after it is transferred 

10 from the hand held device. Alternatively, the data may be uploaded into a local analysis tool 
332 of desktop 308 such as a database or spreadsheet program for final manipulation and then 
storage in asset controller database 78. 

More particularly, in a preferred embodiment of the invention an account manager 
304 who is about ready to visit a business 90 determines the type of information that is 

15 relevant to be collected during the visit. Using the desktop computer, a list of values as well 
as data query forms are downloaded from asset controller database 78 and stored on the local 
desktop computer hard drive, and then transferred to hand held device 168. For example, 
when first taking an inventory of pre-existing assets for a new business 90, a list of valid 
value identifiers for forklift analysis may include the following data elements: 

20 1) Overall customer information 

2) Customer division information 

3) Locations of facilities within each division where forklifts are used 

4) Departments within each facility that use the forklifts 

5) Broad descriptions of the types of ways or industries for which the forklifts are used 
25 6) For each forklift: 

a) Manufacturer/Supplier 

b) Power supply type 

c) Mast type 

d) Tire type 

30 e) Forklift attachments 

f) Forklift type/model 

g) Forklift serial number 
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h) Any label used by a customer to uniquely identify the forklift 

i) Date the forklift went into service 

j) Number of hours that the forklift has been in use according to its meter, 
k) Lease/rental contract information 
5 1) Maintenance history 

m) Maintenance contracts, 
n) Forklift dealer 

o) The number of months/and/or usage hours covered pursuant to the 
manufacturer/supplier warranty, 
10 p) Original purchase cost 

q) Manufacturing date 

r) Forklift condition (e.g., based on a scale such as new or used) 
s) Application rating (e.g., heavy, medium or light) 

t) Administration fees charged for providing financing/maintenance or the like 
15 u) Criteria providing feedback concerning the number of hours at which 

preventative maintenance should be performed 

v) Capacity, typically in pounds or kilograms 

w) Number of hours or shifts the forklift is used each day 

x) Number of days a week that a forklift is used 
20 The tables are downloaded to hand held device 168 using synchronization conduit 326 

and the relationship between forms manager 314 and forms manager computer plug-in 330. 
In practice, the transfer of data value tables and their related values has also included the use 
of a program written in a product called Sybase Powerbuilder from Sybase, Inc. Under such 
circumstances analysis controller database 78 is a Sybase database. Further, desktop 
25 computer 308 may include a different database manipulation program called DBASE acting 
as one of the local analysis tools to review and possibly manipulate data received from hand 
held device 168 or analysis controller database 78 before forwarding it to the receiving 
device. 

The collection of fleet survey data 302 is merely an example of subsystem 300 in use. 
30 Moreover, even when an account manager 304 is collecting fleet survey data 302, it is 
preferred that if some of the data associated with a survey is already stored in database 78 
"(e.g., customer contact information, divisions, or asset locations), it is used to pre-populate 
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appropriate forms 306 to simplify redundant data entry by the account manager. Further, if an 
• error exists based on an inaccuracy in the pre-existing data, account manager 304 can eorrect 
it. 

The collected and manipulated data provides a starting point for each asset 3 1 going 
forward as well as a base foundation for immediate asset fleet analysis since at least some 
historical data has preferably been collected for existing assets. Thus, even at the beginning 
of the utilization of system 300, the initially collected data can be analyzed in accordance 
with pre-existing data involving other fleets, best practices, and the like, to provide immediate 
guidance on how to improve current fleet utilization and efficiency. The same subsystem 
may be used to transfer data and recommendations back to hand held device 168, except that 
this time forms 306 perform a data presentation function as opposed to a query function. As 
suggested above, some analysis of data may be performed directly on hand-held device 168 
although more sophisticated analysis tools 332 are typically associated with desktop computer 
308 or asset controller 5 1 in view of their enhanced computational power and storage 
capabilities. 

Subsystem 300 has been shown using synchronization. It is recognized of course, that 
real-time access is also possible between hand held device and either asset controller 51 or 
desktop computer 308 without the need to use cradle 328. An advantage of real-time access 
between a hand-held device 168 and database 78 is that information may be immediately 
3 transmitted and received, providing access to the full range of data values and associated data 
available in database 78. The uploading and downloading of pre-created data forms 306 to 
help facilitate the collection and analysis of data is also expedited. Further, under some 
circumstances real-time error checking may be available. For example, if an account manager 
304 indicates the number of assets available at a physical location and the actual number in 
15 database 78 is different, the manager can be asked to undertake verification while still present 
at the physical location. Otherwise, to the extent that there are discrepancies, they may be 
considered after data synchronization takes place. 

The same methodology discussed with respect to subsystem 300 may also be used by 
maintenance personnel as discussed with respect to Fig. 8 above. Work order 166 acts as a 
30 pre-populated form 306 transmitted to a hand held device 168. Once the maintenance is 

completed a different form 306 may be used to communicate the necessary maintenance labor 
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and parts information so that a maintenance tracking report 172, invoice 174, and 
determination of inventory-replenishment. 178 may be implemented. ^ 

In accordance with the provisions of the patent statutes, the principles and modes of 
operation of this invention have been explained and illustrated in preferred embodiments. 
However, it must be understood that this invention may be practiced otherwise than as 
specifically explained and illustrated without departing from its spirit or scope. 
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CLAIMS 

What Is claimed is: . . ~ " . 

1. A system for gathering and analyzing data relating to a non-fixed movable 
asset comprising: 

' a local controller located at a first location for acquiring data that is representative of 
at least one operating characteristic of the asset; 

an analysis controller located at a second location that is responsive to said acquired 
data from said local controller for generating an analysis of said acquired data; 

an electronic communications network connected between said local controller and 
said analysis controller and permitting transmission of said acquired data from said local 
controller to said analysis controller; and 

a hand held device receiving at least a sub-set of said acquired data stored in said 

analysis controller. 

2. A system as recited in claim 1, wherein said hand held device is in direct 
contact with said analysis controller. 

3. A system as recited in claim 1, wherein a second computer system is disposed 
between said analysis controller and said hand held device. 

4. A system as recited in claim 3, wherein said second computer system receives 
said acquired data, selectively modifies aspects of said acquired data, and forwards said 
acquired data including said modified aspects, to said hand held device. 

5. A system as recited in claim 1, wherein said hand held includes forms, said 
forms providing data values for the entry of foundational data associated with said data 
values, said data values and said foundational data being transmitted to said analysis 
controller. 

6. A system as recited in claim 5, wherein said foundational data is collected 
prior to said acquired data. 
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7. A system as recited in claim 1, wherein said hand held receives parts data 
associated with the asset, said parts data in the form of at least one of inventory, inventory 
location, and a parts catalog. 

8. A system as recited in claim 1 , wherein said analysis controller includes a 
database, said database including data values, collected data and comparison data being 
available for a selected data value. 

9. A system as recited in claim 8, wherein said comparison data represents one of 
a best practice level and past historical data to provide a base point for comparison with said 
collected data. 

10. A system as recited in claim 8, wherein said collected data includes at least 
user data representing a user accessing the asset. 

11. A system as recited in claim 10, wherein said user data includes at least a sub- 
set of user identification, and access authorization. 

12. A system as recited in claim 1 1, wherein said access authorization includes an 
analysis of user training or user certification with respect to a class of assets including the 
asset. 

13. A system as recited in claim 10, wherein said system includes an authorization 
subsystem, said authorization subsystem including an asset access mechanism to receive said 
user identification from a data transmission point associated with the asset and comparison of. 
said user identification from said data transmission point with said user identification from a 
remote database to confirm the identify of said user. 

14. A system as recited in claim 12, wherein said remote database is one of said 
local controller and said analysis controller. 
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15. A system as recited in claim 12, wherein said user identification is compared 
to access authorization to confirm proper authentication, said asset access mechanism- 
permitting operation of the asset upon proper authentication. 

16. A system for gathering and analyzing data relating to a non-fixed movable 
asset comprising: 

a local controller located at a first location for acquiring data that is representative of 
at least one operating characteristic of the asset; 

an analysis controller located at a second location that is responsive to said acquired 
data from said local controller for generating an analysis of said acquired data; 

an electronic communications network connected between said local controller and 
said analysis controller and permitting transmission of said acquired data from said local 
controller to said analysis controller, said analysis controller including a database, said 
database including data values, collected data and comparison data being available for a 

selected data value; and 

a hand held device including a form, said form providing at least a subset of said data 
values for the entry of foundational data, said foundational data being transmitted to said 
analysis controller and stored in said database. 

17. A system as recited in claim 16, wherein said comparison data represents one 
of a best practice level and past historical data to provide a base point for comparison with 
said collected data. 

18. A system for gathering and analyzing data relating to a non-fixed movable 
asset comprising: 

an asset access device; 

a local controller located at a first location for acquiring data received from said asset 
access device that is representative of a request for user authentication; 

an analysis controller located at a second location that is responsive to said user 
authentication to generate an analysis of said request; and 
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an electronic communications network connected between said local controller and 
said analysis controller and permitting transmission of said request from said local controller 
to said analysis controller. 

19. A system as recited in claim 18, further including an authorization 
subsystem, said asset access device receiving a user identification, said user identification 
being compared with a corresponding user identification stored in said asset controller, and 
providing selective access authorization based on additional user data stored in said asset 
controller for said user identification: 

20. A system as recited in claim 18, wherein said additional user data includes at 
least on of user training or user certification with respect to a class of assets including the 
asset. 
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ABSTRACT OF THE DISCLOSURE 

A computer based system automatically gathers, analyzes, and delivers information 
relating to the procurement and utilization of a plurality of such assets, such as a fleet of 
industrial equipment, so as to maximize productivity and to reduce operating costs and 
administrative burdens. Each of the assets is preferably provided with a data acquisition 
device for sensing and storing one or more operating characteristics associated therewith. 
That information can be transmitted through space to a receiver connected to a local 
controller for storing such information and for transmitting such information to a remote 
analysis system. The remote analysis system automatically updates individual records 
associated with each of the assets with the information received. In response to such 
information, the remote analysis system automatically analyzes the newly provided 
information and schedules maintenance as required. Information associated with the 
maintenance is also recorded electronically to maximize efficiency, provide historical trends, 
automate billing, and control inventory levels. The invention also includes an authentication 
subsystem and a mechanism for using a hand held device to collect and analyze data. 

R00985957 
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these present assigns, sells and sets over unto the Assignee, its successors, legal 
representatives and assigns, for the territory of the United States of America and all foreign 
countries, the entire right, title and interest in and to said invention, said application for 
Letters Patent, including the right to file foreign patent applications corresponding to said 
application, and the right to claim the priority date of said United States patent application 
and any legal equivalents thereof, and any and all Letters Patent or Patents in the United 
States of America and all foreign countries which may be granted therefor and thereon, and 
to any and all divisions, continuations, and continuations-in-part of said application, or re- 
issues or extensions of said Letters Patent or Patents prepared and executed by Assignor on 
even date herewith, the same to be held and enjoyed by the Assignee, as fully and entirely as 
the same would have been held by the Assignors had this Assignment and sale not been 
made. 

AND the Assignors hereby covenant and agree that the Assignors will at any time 
upon the request and at the expense of the Assignee execute and deliver any and all papers 
and do all lawful acts that may be necessary or desirable to perfect the title to said invention 
and to obtain Letters Patent therefor, and the Assignors hereby authorize and requests the 
Commissioner of Patents to issue said Letters Patent to the Assignee in accordance with this 
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Agreement. 



IN TESTIMONY WHEREOF, I hereunto set my hand and affix my seal at 

in the State of Okc 0 this 3/ d ay of O z/oJ^ 2001 . 

(city) (state) (date) (month) 




WITNESSES: 



J.d£ar6n Bly 




(signature) ^ 
(printed name) 




(signature) 




(printed name) 

IN TESTIMONY WHEREOF, I hereunto set my hand and affix my seal at 
Aii^Mte in the State of OA., a this "3 / d ay of CcUkc/- . 2001 . 

(city) (state) (date) (month) 



WITNESSES: 

(signature) £y 

(printed name) 

— — 

(signature) 
(printed name) 
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(city) 



IN TESTIMONY WHEREOF, I hereunto set my hand and affix, my seal at 
, in the State of . this ^/_day of ' 



(state) 



,2001. 



(date) 



(month) 




- Aaron Roth 



WITNESSES: 



(signature) 



(printed name) 




(signature) 
(printed name) 



IN TESTIMONY WHEREOF, I hereunto set my hand and affix my seal at 
rj (aw* re . in the State of flhrh this ^ day, of KlayVmL^ . 2001. 

(city) (state) (date) (month) 



WITNESSES: 





(sigtrature) 



(printed name) 




Z / A/DA L£A/n^ 



(printed name) 
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(city) 



IN TESTIMONY WHEREOF, I hereunto set my hand and affix my seal at 
, in the State of , this d ay of , 2001. 

(state) (date) (month) 



Andrew R Suhy, Jr. 

WITNESSES: 



(signature) 



(printed name) 



(signature) 



(printed name) 

IN TESTIMONY WHEREOF, I hereunto set my hand and affix my seal at 
, in the State of , this day of , 2001. 

(city) (state) (date) (month) 



Brent Parent 

WITNESSES: 



(signature) 



(printed name) 



(sigtrature) 



(printed name) 
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Please address all correspondence and telephone calls and, upon recordation, please 
return this document to: 

RADER, FISHMAN & GRAUER PLLC 
39533 Woodward Avenue, Suite 140 
Bloomfield Hills, Michigan 48304 
(248) 594-0600 

R0127226.DOC 
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SYSTEM AND METHOD FOR DISPOSING OF ASSETS 

RELATED APPLICATIONS 
[0001] This application claims the benefit of U.S. Application 
Serial No. 09/441,289 filed November 16, 1999, U.S. 
Provisional Application Serial No. 60/166,042 filed November 
17, 1999, and U.S. Application Serial No. 09/503,671 filed 
February 14, 2000, and U.S. Application Serial No. 09/714,702 
filed November 16, 2000, all applications hereby incorporated 
by reference in their entirety. 

Background of the Invention 

1 . Technical Field . 

[0002] The present invention relates generally to an electronic 
system and method for use in the field of asset management and 
electronic commerce . 

2 . Description of the Related Art . 

[0003] The field of industrial equipment, such as forklifts, 
includes business entities at several different levels, 
including manufacturers, dealers, third-party financiers, and 
end-user customers. In one common arrangement, the dealer 
maintains an inventory of a wide variety of equipment types 
for rental to its end-user customers (i.e., the dealer's 
"rental fleet"). Some types of equipment in the dealer's 
rental fleet, however, are only infrequently needed by the 
dealer's end-user customers. Accordingly, such seldomly used 
items experience a reduced utilization rate compared to other 
■ items in the rental fleet. The dealer tolerates reduced 
utilization on the seldomly used items for a number of 
reasons, including maintaining customer satisfaction, and, 
hopefully, not giving the customer a reason to "shop around" 
for a new dealer who may have larger inventory of seldomly 
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used pieces of equipment- Conventional methods of conducting, 
business, particularly providing rental fleets, have obvious 
shortcomings, inasmuch as the full economic value of some 
items in the dealer's rental fleet cannot be realized. 
[0004] Another common business arrangement involves a third- 
party financing company that buys pieces of industrial 
equipment from the manufacturer and then leases the equipment 
to the end-user customer. The customer then utilizes the 
industrial equipment (the customer's "fleet") in its business. 
In some circumstance, the customer actively "manages" the 
fleet of industrial equipment, attending to repair and 
maintenance, the acquisition of replacement equipment, and the 
retirement of old or unproductive equipment from the fleet. 
In other circumstances, however, the leasing company performs 
the asset management function. In either set of 
circumstances, challenges to be overcome by fleet managers 
include how to effectively and efficiently determine the 
timing, selection, and acquisition of replacement equipment, 
and the disposal of equipment being retired from the fleet or 
coming to an end of the lease term. 

[0005] Known approaches to deal with the foregoing challenges 
fall mostly into the use of manual methods. For example, 
determining whether to replace a poorly performing piece of 
equipment has typically been based on limited data relating to 
the equipment known by an experienced fleet manager. 
[0006] Another approach known for asset management pertains to 
passenger vehicle fleets and involves a computer-based, 
Internet -enabled vehicle selector program. The vehicle 
selector program provides average values for a plurality of 
different operating parameters and vehicle types that may be 
of interest to a fleet manager considering vehicle 
replacement. These parameters may include average monthly 
maintenance cost, and average miles per gallon. While the 
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vehicle selector program provides at least some useful 
financial and performance information to the fleet manager, 
such a system fails to address the ultimate question fleet 
managers encounter: How does a change (i.e., an addition, or a 
subtraction) in the configuration of my fleet effect its 
overall performance? The known vehicle selector program 
simply does not provide information as to how a combined fleet 
would perform. 

[0007] Another challenge, particularly acute for third-party 
financing companies, involves how to effectively and 
efficiently dispose of assets whose lease has ended, or will 
-end in the near future. Conventional analysis approaches have 
been haphazard at best. They have included utilization of 
well-known auction systems, posting of off -lease equipment on 
electronic bulletin boards and the like for sale purposes, as 
well as utilization of consignment networks- One key 
shortcoming of all these known systems of disposing of end-of- 
lease assets manifests itself in the failure to fully realize 
the full, remaining economic value of the asset. One factor 
contributing to this shortcoming involves the lack of 
information available to potential purchasers, renters and 
lessees. Information concerning the condition, treatment, 
and, particularly, the maintenance history of the asset during 
its operating life up to the time the asset is being offered 
for disposal are all important in determining a sales price, 
but are frequently unavailable. In any event, such 
information is never convenient to obtain. For example, it is 
known in the passenger vehicle fleet industry to make some 
level of maintenance history data on particular vehicle 
available to the potential- purchaser. However, to obtain this 
data, the potential purchaser must make a telephonic request 
to the asset's fleet manager, who manually looks up the 
information, and provides it (e.g., by way of facsimile) to 
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the potential purchaser if. it is even available. Obtaining 
such information, therefore, involves a significant 
investment, both in time and effort. The investment is 
entirely lost if the purchase is not consummated, and is still 
partially lost even if the asset is finally transferred. The 
time lag involved in obtaining the information also leads to 
undesirable inefficiency. For example, a purchaser may have 
to make a quick decision regarding whether or not to buy a 
first asset, which would preclude a lengthy investigation of a 
second asset (e.g., the first asset may be sold by the time 
the investigation of the second asset has been completed) . 
This is particularly inefficient if the second asset is a 
better "fit" for the purchaser than the first asset. 
[0008] There is therefore a need for a system and method for 
facilitating transactions, and for managing assets of a fleet, 
that minimizes or eliminates one or more of the types problems 
exemplified above. 

Summary of the Invention 
[0009] In one aspect of the present invention, an electronic 
system is provided for facilitating transactions, particularly 
rental transactions. The electronic system provides, in- 
effect, a "virtual" rental fleet available to a user of the 
system, such as a dealer. The system includes an asset 
configuration unit, a market database, a market search module, 
and a communications interface. 

[0010] The configuration unit is responsive to input data 
-provided by a first user of the system for generating a 
profile of an asset. The asset profile comprises asset, 
specification data and a bid definition. In a preferred 
embodiment the bid definition outlines parameters associated 
with a rental transaction of the asset. The market database 
is configured to store a plurality of asset profiles. The 
market search module is configured to search the market 
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database, based on search parameters specified by a second 
user, and generate an identification of assets. The bid 
module is configured to allow the second user to select one of 
the assets on which to bid. The bid module is also adapted to 
5 provide rental options to the second user, based on the bid 
definition for the asset. Finally, the communications 
interface is configured for facilitating the electronic remote 
access by the second user of the system. 

[0011] Through the foregoing, a dealer or the like is provided 
10 access to a "virtual" rental fleet of assets, some of which 

are not owned or controlled by the dealer. The system allows 
a user, such as a dealer, to satisfy the requirements of the 
dealer's end-user customer without having to maintain 
infrequently used items in the dealer's own rental fleet 
15 (which experience low utilization rates and thus return on 

investment.) Additionally, the electronic system also allows a 
user, such as a dealer, who has its own under-utilized assets 
to consign such assets for rental by third parties, thereby 
allowing an increased, effective utilization rate. 
20 [0012] In another aspect of the present invention, an electronic 
system is provided for facilitating transactions, including, 
for example, assets disposal. The system, according to this 
aspect of the present invention, provides detailed information 
concerning an asset including the maintenance history data so 
25 that the user, a potential purchaser, rentee or lessee, may 
evaluate the asset. The system includes a first database, a 
market search module, and a communications interface. 
[0013] In a preferred embodiment, the first database is 
configured to store information associated with a plurality of 
30 assets, such as pieces of industrial equipment. The market 
search module is configured to search the first database, 
based on search parameters specified by the user in 
anticipation of at least one of a purchase, rental and lease 
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transaction. The market search module is also adapted to 
generate an identification of assets in accordance with the 
specified search parameters. At least one of the identified 
assets has a description that includes maintenance history 
data of the asset. The communications interface is configured 
to facilitate electronic remote access of the system by the 
user, which, in one embodiment, occurs over the Internet. 
[0014] The electronic system, according to this aspect of the 
present invention, maximizes value extraction by making 
detailed information concerning the asset readily available to 
the user. In particular, the maintenance history of the asset 
constitutes information that may increase the price obtained 
for the asset. For example, the maintenance history data is 
particularly important to a dealer class of users of the 
system who anticipate sub-renting or sub-leasing the asset for 
a short term, inasmuch as a common commercial practice places 
the responsibility of maintenance on the dealer, not the end- 
user customer. Availability of information such as 
maintenance history data electronically, and immediately, 
substantially minimizes or eliminates the cost associated with 
information acquisition. 

[0015] In a refinement of the proposed asset disposition, a 
subsystem is disclosed, which compares a subset of .all assets 
within the inventive system with a series of pre-defined 
conditions to determine if an action needs to be taken with 
respect to asset disposition. If a pre-defined condition is 
met, the system provides a ranked hierarchy of options based 
on the pre-defined condition that has been met. Associated 
with each option is the cost of invoking it, and the reasons 
why it is recommended for consideration. The hierarchy of 
options and the option determination assumptions are 
optionally reviewed and then presented to the asset user for 
cons ider at ion . 
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[0016] In another aspect of the present invention, an electronic 
system for modeling a simulated fleet is provided. The 
capability to model a simulated or "fantasy" fleet of assets 
provides the user with an effective and efficient mechanism to 
perform "what if" analyses. The user can then use the results 
to evaluate what effect proposed changes to an existing fleet 
would have on overall fleet performance. The electronic 
system for modeling a simulated fleet includes a simulated 
fleet configuration unit, a reporting and analysis module, and 
a communications interface. 

[0017] The simulated fleet configuration unit is provided for 
allowing a user to add a plurality of assets to the simulated 
fleet. Each asset is defined as having at least one parameter 
associated therewith. For example, in one embodiment , the 
parameter may be a total hourly cost to operate the asset. 
The reporting and analysis module is configured to generate a 
report having a composite output value that corresponds to the 
parameter, and, is characteristic of all of the assets in the 
simulated fleet. For example, the composite output value may 
be a composite total hourly cost for all the assets in the 
simulated fleet. Finally, the communications interface is 
configured to facilitate electronic remote access of the 
system by the user. For example, in a preferred embodiment, 
the communications interface allows access to the system over 
the Internet. This reduces the time and effort to obtain 
information. The system, according to this aspect of the • 
present invention, provides a more effective asset management 
tool than available using conventional systems. 
[0018] In a preferred embodiment, some of the assets contained 
in the simulated fleet correspond to assets already contained 
in the user's existing fleet. The remainder of the assets in 
the simulated fleet correspond to new or used assets proposed 
for acquisition by the user. The report generated by the 
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reporting and analysis module contains a composite output 
value representative of all the assets in a simulated fleet, 
namely, both the existing assets, and the proposed assets to 
be acquired. The report may be compared to a second report 
generated based on the performance of the assets in the 
existing fleet alone. Comparison of the two reports by the 
user allows accurate evaluation of the impact of the proposed 
changes . 

[0019] Other objects, features, and advantages of the present 
invention will become apparent to one skilled in the art from 
the following detailed description and accompanying drawings 
illustrating features of this invention by way of example, but 
not by way of limitation. 

Brief Description of the Drawings 
[0020] Figure 1 is a simplified diagrammatic and block diagram 
view of a fleet management and electronic commerce system in 
accordance with the present invention; 

[0021] Figure 2 is a simplified block diagram view illustrating 
functional modules according to the invention; 

[0022] Figure 3 is a simplified diagrammatic view of a screen 
output of the system of Figure 1, including a link to further 
fleet information; 

[0023] Figure 4 is a simplified diagrammatic view of a screen 
output of the system of Figure 1, showing detailed fleet 
inf ormat ion ; 

[0024] Figure 5 is a simplified flowchart diagram showing the 
steps for a method of adding an asset to a fleet; 
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[0025] Figure 6 is a simplified diagrammatic view of a screen 
output of the system of Figure 1, illustrating greater detail 
of a selected asset, including maintenance history data; 

[0026] Figure 7 is a simplified flowchart diagram illustrating 
the steps for a method of consigning an asset for sale, rental 
or lease; 

[0027] Figure 8 is a simplified diagrammatic and block diagram 
view showing, in greater detail, the process for generating 
asset specification data and a bid definition; 

[0028] Figure 9 is a simplified diagrammatic view of a screen 
output of a fleet search module of the present invention ; 

[0029] Figure 10 is a simplified diagrammatic view of a market 
search criteria input form; 

[0030] Figure 11 is a simplified diagrammatic view of a screen, 
output showing an identification of assets resulting from the 
market search; 

[0031] Figure 12 is a simplified diagrammatic view of a screen 
output showing purchase, lease and rental options; 

[0032] Figure 13 is a simplified diagrammatic view of a screen 
output showing assets contained in a simulated or "fantasy" 
fleet; 
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[0033] Figure 14 is a simplified diagrammatic view of a screen 
output illustrating a report, including a composite financial, 
parameter, for a simulated fleet; 

[0034] Figure 15 is a simplified flowchart diagram illustrating 
the steps for comparing assets with pre-defined conditions and 
then providing ranked options based on the condition met with 
respect to asset disposition; and 

[0035] Figure 16 is a simplified diagrammatic view of a screen 
output illustrating a report showing the status of asset 
disposition based on available options and their 
cons i de rat ion . 

Detailed Description of the Preferred Embodiments 
[0036] Referring now to the drawings wherein like reference 
numerals are used to identify identical components in the 
various views, Figure 1 is a simplified diagrammatic and block 
diagram view showing an electronic system 2 0 for managing, 
tracking and conducting electronic commerce, with respect to a 
plurality of assets designated 221, „., 22n. The assets 221, 

22n are illustrated as being a plurality of pieces of 
movable industrial equipment, such as a plurality of 
conventional forklifts or similar machinery, used in the 
manufacture of goods in a typical factory environment. It 
should be understood, however, that system 20 is configured 
for operation with a wide variety of assets. System 20 is 
further configured to manage, and facilitate commercial 
transactions involving other assets (i.e., those not tracked) 
that are consigned or otherwise made available on an 
electronic market established by system 20. 
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[0037] Before proceeding to a detailed description of system 20 
keyed to the drawings, a general overview of the features of 
the present invention will be set forth. 

[0038] Electronic system 2 0 overcomes a problem identified in 
the Background, namely, the inability of prior systems to 
significantly facilitate business transactions that could 
increase utilization of infrequently rented assets in a user's 
rental fleet. Electronic system 20 includes functionality 
that allows users, in-effect, to consign assets on an 
electronic market in a manner that makes detailed information, 
such as maintenance history, readily available. Through the 
foregoing, users of system 2 0 having under-utilized equipment 
may use system 2 0 to "post" such equipment on the electronic 
market for rental, lease, or the like by other users of the 
system. Not only does system 2 0 enable some users to increase 
utilization of under-utilized assets, other users, (e.g., 
dealers) who have an occasional need for some equipment (e.g., 
to provide to their end-user customers) , can rent or lease 
equipment from the market in contemplation of sub-rental or 
sub-lease, without having to actually own the equipment. 
Detailed information, such as maintenance history data, allow 
users to make informed decisions. Equipment selection 
efficiency is significantly improved since it is commonplace 
for users such as dealers to be responsible for the 
maintenance of equipment they sub - rent . Well -maintained and 
problem free equipment will likely be in the highest demand, 
and draw the highest lease and rental rates. 

[0039] Another shortcoming set forth in the Background involves 
the failure to realize an assets' full value upon disposal at 
the end of a lease term. Conventional systems are inefficient 
and inconvenient for making desired information available to 
new owners, lessees, and renters prior to their making 
decisions concerning such transactions. In accordance with 
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the present invention, electronic system 2 0 is configured for 
facilitating transactions by creating an electronic market. 
In particular, system 20 is configured to allow remotely 
located users to electronically search the market based on 
search parameters they specify, and obtain a detailed 
description of the assets, including the maintenance history 
data. System 20 also includes a bidding mechanism configured 
to allow the user to bid on the assets. The contemplated 
transactions can be closed electronically. 
[0040] As stated in the Background, one shortcoming of 
conventional asset management systems involves the absence of 
an electronic "what if" analysis tool. The present invention 
overcomes this shortcoming, enabling the creation of a 
simulated ("fantasy") fleet. A user. of system 20 may add a 
plurality of assets to the simulated fleet, including 
currently held or controlled assets in an existing fleet, such 
as assets 221, 22n, as well as new and/or used assets 
available in a "market" portion of system 20. The simulated 
fleet analysis tool allows the user to evaluate proposed 
changes to an existing fleet. The tool may be used to compute 
parameters of interest that are characteristic of all the 
assets contained in the simulated fleet, which can then be 
compared to the same parameters for the user's existing fleet. 
[0041] Referring now to Figure 1, system 2 0 is configured for 
electronic remote access by a plurality of remote users, 
designated 231, 23n, through remote client computers 241, 
24n, over a global computer network, such as Internet 26. 
Private networks or dial-up connecting may also be used. 
Inasmuch as system 20 performs a variety of functions, such as 
tracking and management of assets, as well as facilitating 
electronic commerce, the users 231, 23n may fall into a 
plurality of user classes, which are accommodated within 
system 20. 
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[0042] With continued reference to Figure 1, remote client 
computers 241, 24n may be any one of a plurality of well 
known computer systems, such as, for example, a personal 
computer (PC) running a Microsoft Windows operating system 
(e.g., Windows 95, Windows 98, Windows NT Workstation, and 
Windows 2000) , or a Macintosh computer (Apple Computer) . When 
used with Internet 26, remote client computers 241 24n are 

preferably configured to include a conventionally, 
commercially available web browser, such as, for example, 
Netscape Navigator 4 . 0 or higher, commercially available from 
Netscape Communications Corporation, or Microsoft Internet 
Explorer 4 . 0 or higher, commercially available from Microsoft 
Corporation, Redmond, Washington. The browser included on 
client computers 241, 24n preferably includes the 
capability of establishing a secure connection through 
Internet 26, by way of a firewall system 44 with web server 
30, for example, using a Secure Sockets Layer (SSL) protocol 
described below. Of course, other mechanisms for establishing 
a secure connection, such as the S-HTTP protocol may be used 
so long as both the client computers 24 and web server 3 0 are 
configured to include software compliant with the chosen 
protocol. Moreover, the present invention recognizes that 
different client software may be required when using private 
networks or a dial-up connection. 

[0043] System 20 interfaces with a tracking and management 
system 28, and preferably includes a first computer system, 
such as a web server 30, a second computer system, such as an 
application server 32, and a third computer system, such as a 
database server 34. One or more of the servers may be 
combined, depending on the size and complexity of system 20. 
Database server 34 is coupled to a market database 3 6 and a 
global asset database 38 comprising a fleet database 40 and a 
preconf igured asset database 42. In the client-server 
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architecture described herein, the " server " ; provides the 
information to the "clients" . Electronic system 20 may 
further include, in an alternative embodiment a firewall 
system 44 . 

[0044] Tracking and management system 2 8 is configured to 
automatically gather, analyze, and deliver information 
relating to the procurement and utilization of assets 221, 
22n, so as to maximize productivity and to reduce operating 
cost and administrative burdens. Each asset may be provided 
with a data acquisition device for sensing and storing one or 
more operating characteristics associated with the asset. 
Such information can be transmitted to a receiver connected to 
a collection controller contained within system 28 for 
purposes of storing such information. System 28 may be 
further configured to automatically update individual records 
associated with each of the assets with information received, 
including for example, maintenance history information, and 
hour-meter readings. System 28 is operatively coupled to 
electronic system 20, particularly database server 34, as 
shown in Figure 1. This coupling allows system 20 to be 
updated with current information regarding the tracked assets 
221, 22n. Users 231, 23n may then access and review the 
status of their fleets, over Internet 26, using system 20 as a 
gateway. Tracking and management system 2 8 may be a system 
as described in co-pending application U.S. Serial No.: 
09/441,289, filed 11/16/99 entitled "APPARATUS AND METHOD FOR 
TRACKING AND MANAGING PHYSICAL ASSETS" , hereby incorporated by 
reference in its entirety. 

[0045] Web server 3 0 operates as a communications interface for 
facilitating electronic remote access of system 2 0 by users 
231, 23n via client computers 241, 24n when using 
Internet 26. Web server 30 is preferably compatible with the 
ubiquitous HyperText Transfer Protocol (HTTP 1.1), and 
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includes the capability of establishing a secure connection 
with client computers 241, 24n via, for example, the 
publicly available Secure Sockets Layer (SSL) protocol. 
Version 3 . 0 of the SSL protocol is commercially available from 
Netscape Communications Corporation. Web server 3 0 may 
comprise suitable hardware configured to handle anticipated 
traffic (e.g., requests, responses) therethrough, and may 
further execute conventional, commercial software, such as 
Windows NT 4 . 0 operating system software running Microsoft 
Internet Information Server (IIS 4.0) software, both 
commercially available from Microsoft, Redmond, Washington 
USA. 

[00461 Application server 32 is configured for running 
components of system 20, described functionally below, as well 
as serving reports. Application server 32 may comprise 
conventional, commercially available hardware, and include 
conventional, commercially available software such as Windows 
NT 4.0 operating system software, Microsoft Transaction Server 
2.0 transaction server software, as well as a conventional, 
commercially available reporting engine software, such as 
Power Builder or Crystal Reports. 

[0047] Database server 34 is configured for executing all 
database serving within electronic system 20, and may comprise 
suitably adapted hardware selected, in part, on anticipated 
traffic and data access response- time standards set for system 
20. Database server 34 may include conventional, commercially 
available software, such as Windows NT 4 . 0 operating system 
software, and Microsoft SQL server 7.0 database server 
software, both from Microsoft, Redmond, Washington USA. 
[0048] Web server 30, application server 32, and database server 
34 define a mult i- tiered computing environment configured to 
achieve and implement the functionality to be described in 
greater detail hereinafter. It should be understood that 
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alternate architectures may be employed, achieving the same, 
functionality, yet remain within the spirit and scope of the . 
present invention. 

[0049] System 2 0 organizes asset information into several 
logical groups. Market database 36, shown diagrammatical ly in 
Figure 1, is configured for storing a plurality of asset 
profiles, associated with a corresponding plurality of assets, 
destined for disposal on an electronic market. Contemplated 
transaction types include sale, rental and lease. The asset 
profile includes two parts: asset specification data and a bid 
definition. The asset specification data includes a variety 
of details about the asset, as well as its maintenance 
history. The bid definition outlines the parameters 
associated with the above-described commercial transactions 
contemplated for the asset. Market database 36 is illustrated 
as a logically separate database, although it should be 
understood that market database 36, in alternative 
embodiments, may be implemented together on the same physical 
hardware as the global asset database 38. Market * database 3 6 
is configured for rapid retrieval of asset information, as 
desired to facilitate the electronic commerce functionality of 
electronic system 20. 

[0050] Fleet database 4 0 is configured to store asset 
specification data for assets contained in fleets being 
managed by system 20. As used herein, u fleet" is a logical 
grouping or association of one or more assets, which may 
include assets 221 22n being tracked and managed by system 

28. A "fleet" may be either (i) a current fleet, or (ii) a 
simulated or "Fantasy" fleet. An existing fleet is a fleet 
containing assets under the control of a user, for example, 
through ownership or lease. A "Fantasy" fleet may contain (i) 
any assets in any of the user's existing fleets ("held 
assets"), (ii) new or used assets not held or controlled by 
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the user such as may be available for purchase, rental, or 
lease from third-parties via the market, or (iii) fictional 
assets having a predetermined usage, and performance profile, 
from the preconf igured asset database 42 . 

[0051] Preconf igured asset database 42 includes a plurality of 
asset specifications for various asset types. The asset 
specification includes values that may be a composite of a 
plurality of specific, actual assets of the same or similar 
type. For example, a model "A" forklift from a particular 
manufacturer may have an average monthly maintenance cost 
based on a long history of tracking the maintenance cost for 
model "A" forklifts. A preconf igured asset brings these 
composite values when added to a fleet. 

[0052] Firewall system 44 is disposed between the connecting 
network such as Internet 26, which is generally considered 
"insecure", and the secure, private network on which servers 
30, 32, and 34 reside and execute. Firewall system 44 may be 
implemented in software, hardware, or a combination of both. 
As is known generally, firewall system 44 is configured to 
intercept messages destined for web server 30, or exiting 
therefrom, and to examine such messages, and block those that 
do not meet security criteria. Firewall system 44 enhances 
the security, and hence the integrity, of the electronic 
market established by the invention. Firewall system 44 may 
comprise conventional devices and methodologies known to 
those of ordinary skill in the art . 

[0053] Figure 2 is a block diagram view of the functional 
modules implemented on electronic system 20. Functional 
modules include a login or authentication module 46 , a fleet 
module 48 comprising a simulated fleet module 50 and a current 
fleet module 52, a fleet search module 54, a market module 56 
comprising a market search module 58 and a bid module 60/ a 
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reporting and analysis module 62, and a bid definition module 
64. 

[0054] Login 46 provides authentication functions, principally 
through a user ID/password approach. In one embodiment, 
electronic system 20 includes several classes of users: a 
guest class, a member class, and a dealer class. A guest is 
characterized as having no member privileges, but can view 
assets available in market database 36, as well as other 
public areas of electronic system 20. A member has an 
enhanced set of privileges. A member may create an actual 
fleet, and/or a simulated fleet, may conduct searches of the 
assets contained in the members existing and/or simulated 
fleets, may search market database 3 6 and bid on selected 
assets, run reports and conduct analyses, as well as place 
assets in market database 36 for disposal. A dealer has 
access to the features available to members, but in addition, 
has access to a set of dealer tools generally unavailable to 
members, as discussed further below. Finally, electronic 
system 2 0 provides for an administrative class of users having 
heightened, administrative rights and privileges, for example 
to perform maintenance or reconfigure system 20. 
[0055] Before new users can practically use system 20, they must 
register. Accordingly, associated with login module 46 is a 
registration module (not shown) that allows a new user to 
register, typically as either a member, or a dealer. For 
registration activities and/or user profile changes, web 
server 3 0 and the corresponding client computer 24 communicate 
via a secure, encrypted connection, such as via the SSL 
encryption protocol. 

[0056] Regarding existing users, login module 4 6 is configured 
to automatically log the user in upon detection of an auto- 
login "cookie" . A "cookie" is a message that is given to a 
client (e.g., a web browser on a client computer 241, , 24n) 
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by a server (e.g.*, web server 30). Client computer 241 will 
cache the cookie, and store the cookie in a file on the client 
computer 241 if the cookie is a so-called "persistent" cookie. 
A part of the message is a description of the range of URLs 
(e.g., http://www.ironrhino.com) for which that cookie is 
valid, and a time period for which the cookie will persist. 
Any future HTTP requests by the client computer that fall 
within that URL range (e.g., http : //www. ironrhino . com) and 
valid time period will include, with the HTTP request, the 
current value of the cookie to the server. In operation, 
electronic system 20 is configured to query a user 23 using a 
client computer 24 to determine whether the user wishes to 
save the user-login and password. If the user responds "YES" , 
then electronic system 20, particularly web server 30, sends a 
cookie to the corresponding client computer 24, wherein the 
cookie is stored in a file. When the user subsequently 
accesses the URL from which the home page of system 2 0 are 
served, the browser portion of client computer 24 determines a 
match and will send the auto-login cookie, (containing 
login/password) to electronic system 2 0 for authentication 
purposes. Upon successful login, login module 46 directs the 
user (e.g., member or dealer) to the user's start page (best 
shown in Figure 3) . 

[0057] With continued reference to Figure 2, fleet module 48 is 
configured to allow members and dealers to add their current 
fleet information into electronic system 20 for reporting, 
tracking and analyzing by module 62. It should be understood 
that such activities provide much information regarding the 
status of the fleet, and upon which important business 
decisions can be based. Simulated fleet module 50 is 
configured to allow a user 23 to access, add, view, edit and 
delete assets in a simulated fleet. According to the 
invention, the "Fantasy fleet" feature allows accurate and 
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immediate "what if" analysis, unavailable through the use of 
conventional, systems . Current fleet module 52 allows a member 
or dealer to access, add, view, edit, or delete assets in one 
or more existing/actual fleets associated with the registered 
member or dealer. 

[0058] Figure 3 shows a user's "start" page 66 generated by 
fleet module 48 after a successful login. Start page 66 
includes a navigation pane, a search pane 70, a descriptive 
text pane 72, an advertising/promotions pane 74, an existing f 
fleet information pane 76, and a simulated or "fantasy" fleet 
information pane 7 8 . 

[0059] Navigation pane 68 includes, in the illustrated 
embodiment, a plurality of user-invoked (e.g., via "clicking" 
with a mouse or other pointing device) functions or operations 
that enable efficient navigation through the various modules 
of electronic system 20. Navigation pane 68 includes a Home 
button 80, a Search button 82, a "My Fleet" button 84, a 
"Fleet Builder" button 86, a STORE button 88, a Library button 
90, a Reporting button 92, and a FAQ (Frequently Asked 
"Questions) button 94. Wherever -the user navigates to within 
system 20, navigation pane 68 will appear at the top of the 
screen. 

[0060] The "Home" button directs system 2 0 to take the user back 
to an initial login/registration page, which is then displayed 
on the user's client computer 24. Search button 82 invokes 
fleet search module 54, which is configured to search the 
user's fleets to identify assets based on user specified 
search criteria (e.g., make, model, and year of manufacture.). 
The "MY" FLEET" button 84 invokes fleet module 48, taking the 
user to the user's start page 66. The "FLEET BUILDER" button 
86 invokes a fleet builder wizard to lead the user through the 
steps of creating a new fleet of actual assets, or a simulated 
fleet. The "STORE" button 88 invokes market module 56, 
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providing the user with access to conduct searches of market 
database 36 to identify assets for purchase, rental or lease. 
Library button 90 invokes a library module (not shown) that 
allows the user to visit the on-line library of system 20 for 
access to downloadable documents. Reporting button 92 invokes 
reporting and analysis module 62 for obtaining reports 
containing analysis results for fleet assets or market items. 
FAQ button 94 invokes FAQ module (not shown) , allowing the 
user to access questions and answers of interest to the users 
of system 20. 

[0061] Search pane 7 0 includes pull down menus for defining 
search parameters for conducting a search of either market 
database 36, or fleet database 40. The search is invoked, in 
an illustrated embodiment, by selecting (i.e., "clicking") on 
a "Search" button. 96 . 

[0062] The descriptive text pane 72 is configured to display 
predetermined text to the user, based on user interaction with 
electronic system 20. For example, descriptive text pane 72 
may include information instructing the user as to the 
organization of start page 66, and the available options, such 
as creating an actual fleet or a fantasy fleet. 
[0063] Advertising/promotions pane 74 is configured to display 
advertising or promotions that may be available. For example, 
certain pieces of equipment may be on a "lease special" , more 
details of which may be found in the site "STORE" (i.e., via 
"clicking 11 on "STORE" button 88 on the user's start page). 
[0064] Current fleet information pane 7 6 comprises the interface 
through which a user interacts with electronic system 20 to 
create an actual or a current fleet, and to edit or delete a 
fleet. Fleet information pane 76 includes, in the illustrated 
embodiment, a "Create Fleet" button 98, an Edit button 10 0, a 
Delete button 102, a radio button 104, and a link 106. 
Selecting (i.e., "clicking") on the "Create Fleet" button 98 



65678-0042 (5672 DCCSP) 



causes fleet module 48 to create a new fleet record in fleet 
database 40- In one embodiment, the record includes a fleet 
name, and a location. Edit button 100, when selected by the 
user, invokes current fleet module 52, which is configured to 
allow the user to edit the fleet name and/or location of the 
fleet selected by radio button 104. Note that in Figure 3, 
only one existing fleet (i.e., the "Denver Division") is 
illustrated; however, when two or more existing fleets are 
displayed, each have a corresponding radio button 104 
associated therewith, and only one of the radio buttons may be 
selected at a time (i.e., is darkened) . The fleet having a 
darkened radio button is the "selected" fleet for purposes of 
Edit button 100, and Delete button 102. Selecting the delete 
button 102 causes current fleet module 52 to delete the 
selected fleet from database 40. In the fleet information 
pane 76, in the illustrated embodiment, each existing fleet 
under the heading u Fleet Name" is configured to operate as a 
link to another page generated by system 20, particularly 
current fleet module 52. This "linked" page provides an 
identification of the assets contained in the fleet. The 
portion of the "linked" page that shows the asset 
identification is illustrated in Figure 4 (portions of the 
"page" have been omitted for clarity, like the Navigation pane 
68, which has was already been shown in Figure 3) . 
[0065] With continued reference to Figure 3, Fantasy Fleet 
information pane 78 includes a "Create Fantasy Fleet" button 
108, an Edit button 110, a Delete button 112, a radio button 
114, and a link 116. Pane 78, and buttons 108, 110, 112, 114, 
and link 116 operate in a substantially identical fashion to 
pane 76, buttons 98, 100, 102, 104, and link 106, as described 
above, except that they pertain to the Fantasy Fleets. 
[0066] Figure 4 shows a screen output current fleet module 52, 
responsive to a user's selection of link 106 in Figure 3. 
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Figure 4 includes an identification of the individual assets 
included in the "Denver Division" fleet. In. an illustrated 
embodiment, the identification includes a listing of the 
following parameters for each asset: a serial number, a make, 
a model, a capacity (pounds) , an asset type, an application 
rating, a usage parameter, a utilization parameter (percent) , 
and a cost/hour (U.S. Dollars) . 

[0G67] The view illustrated in Figure 4 includes an "Add Asset" 
button 118, an "Add Fleet Charge" button 120, an Edit button 
122, a Delete button 124, a plurality of radio buttons 12 6, a 
Move button 128, a pull down menu 130 including entries 1301, 
1302, 130n, and a link 132. The "Add Asset" button 118, 
when selected by the user, causes current fleet module 52 to 
add assets to the selected fleet. This process will be 
described in greater detail below. The "Add Fleet Charge" 
button 120, when selected, causes a charge (i.e., monetary 
charge) to be applied pro-rata to each of the assets included 
in the selected fleet. Edit button 122, and Delete button 
124, when selected by the user, respectively, cause current 
fleet module 52 to allow the user to edit, or delete an asset 
from the selected fleet. Which asset is affected is 
determined by which radio button 12 6 is selected. The edit 
function allows the user to edit the asset specification data 
associated with the asset. The "Move" button 128, when 
5 selected by the user, moves an asset (as selected by the radio 
button 126) , from the current fleet to the fleet chosen by the 
user from one of the entries 1301, 1302, 130n in pull down 
menu which are actual fleets as well as to thereby move real, 
existing assets between existing fleets. 
0 [0068] Figure 5 is a simplified flowchart diagram illustrating 
the steps for a method of adding an asset to a fleet. The 
method begins in step 134. The "Add Asset" function may be 
invoked from either simulated fleet module 50 or current fleet 
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module 52 . The description of Figure 5 will be made with 
reference to module 52, although it should be understood that 
module 50 could be executing the steps as well. 
[0069] In step 13 6, current fleet module 52 obtains basic asset 
specification data responsive to input data provided by user 
23 . While the particular types of information contained in 
the asset specification data will vary depending on the 
particular asset type involved, in the illustrated embodiment 
where the asset comprises an industrial piece of equipment, 
namely a forklift, the asset specification data is divided 
into four subgroups: "basic", "additional", "usage" , and 
"performance". In one embodiment, the "basic" asset 
specification data may include an asset type (e.g., a standard 
forklift) , a make/model designation, a serial number, a year 
of manufacture, a capacity (e.g., in pounds), and commentary 
text. In a constructed embodiment, "clicking" the "Add Asset 7 ' 
button causes a dialog box to be presented to the user having 
four tabs labeled "basic", "additional", "usage" and 
"performance" . The user moves from tab to tab, filling out 
respective forms, comprising input boxes and pull down menus. 
When complete, the user "clicks" on a "SAVE" link. The method 
then proceeds to step 13 8. 

[0070] In step 138, module 52 obtains "additional" asset 
specification data, which in the illustrated embodiment of a 
forklift may include a mast type (e.g., quad, standard, STD, 
TSU, etc.), a tire type (e.g., cushion, foam filled, non- 
marking, pneumatic, polyurethane , etc.), a "fuel type", a mast 
height, a tilt selection, an attachment description, an asset 
description, a condition, and an accounting system asset 
identification (ID) number, and a lease ID number. As will be 
described below, reporting and analysis module 62 generates 
reports that include financial parameters, on both a per-asset 
and a per-fleet basis (e.g., average monthly cost). Part of 
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the cost analysis derives from how much is paid monthly to 
lease or - rent the asset. This cost information, in one - 
embodiment, is derived from information found in a separate 
accounting/leasing system (not shown) , and is identified and 
retrieved by electronic system 2 0 using the accounting system 
asset ID number, and lease ID number, provided as "additional" 
asset specification data in step 138. In an alternate 
embodiment, where the asset being added is not an asset 
covered under a lease in a leasing system in electronic 
communication with system 20, further financial -option 
information will be obtained from the user for the asset being 
added, which may include a purchase price (including 
applicable depreciation information so as to enable 
calculation of a monthly cost amount) , a lease/rental amount, 
a i eaS e-life rental-term, and a residual amount for 
l ease / r ent. The method then proceeds to step 140. 
[0071] In step 140, current fleet module 52 obtains "usage" 
asset specification data, which may comprise the following: an 
acquired-f rom name (i.e., name), an application rating (e.g., 
light, medium, heavy) , a- date in service, an active asset 
designation (i.e., yes or no), a number of shifts used, an 
original cost per hour, an original usage, an original 
utilization, as well as other features. The method then 
proceeds to step 142. 

[0072] In step 142, current fleet module 52 obtains 
"performance" asset specification data comprising an original 
hour meter reading, a number of warranty months, a number of 
warranty hours, a date warranted, a date warranty removed, an 
original equipment cost, a list price, a preventative 
maintenance (PM) hours specification, and a burden labor rate. 
It should be appreciated that the original hour meter reading 
provided to system 20 in step 142 has a date associated 
therewith. The meter reading and date form a data pair. 
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Future service events on the asset will generally also include 
further meter readings, such that the fleet database will have 
a plurality of date/meter-reading data pairs, each having a 
different date attached to it, for the life of the asset. 
[0073] When the user completes the entry of the asset 
specification data, the user will be prompted to enter 
maintenance history data for the asset being configured. As 
shown in decision block 1-44, current fleet module 52 
determines, through a suitable prompt to the user, whether 
further maintenance history data is available. If the answer 
is "YES" , then the method branches to step 146. 
[0074] In step 146, current fleet module 52 obtains the next 
item of maintenance history data for the asset being 
configured. Maintenance history data may include the job 
date, a description of the problem (e.g., work-related, abuse, 
breakdown, regular maintenance) for which maintenance was 
required, a diagnosis, a commentary, a description of the 
actual work performed, the name of the vendor performing the 
work (if applicable) , whether the maintenance source is 
internal /external, whether covered under warranty, a 
description of the part replaced, a length of service, and an 
hour meter reading (usage) . Financial parameters for the 
maintenance items obtained from the user may include: Invoice 
Number, Invoice Date, Invoice Due Date, Invoice Paid Date, 
Total Cost, Labor Rate, Parts Tax, Labor Tax, Labor Hours, 
whether the item is Taxable, Exchange Rate, and Exchange Date. 
Financial parameter values for maintenance items may be used 
to determine total maintenance cost, and average maintenance 
cost for the asset. The method then loops back to decision 
element 144. If the answer to decision element 144 is "NO", 
then the method branches to step 148. 

[0075] In step 148, the asset specification data, including 
maintenance history data, for the asset being configured is 
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stored in fleet database 40. The method then proceeds to step 
150, where the "add asset" portion of the current fleet module 
52 ends. 

[0076] The process for adding an asset to a "Fantasy Fleet", 
although not shown specifically, is the same as outlined above 
for adding an asset to a current fleet, except that fleet 
module 48 invokes simulated fleet module 50, rather than 
current fleet module 52. 

[0077] Figure 6 shows a screen output generated by current fleet 
module 52 for a configured asset. The configured asset 
comprises asset specification data 154 including maintenance 
history data 156. In the example illustrated in the drawing, 
the user reaches the screen of Figure 6 by "clicking" on link 
132 in Figure 4. Through the foregoing, a user wishing basic 
information (i.e., a simple identification) of the assets in 
the user's fleet need proceed no further than Figure 4. 
However, for greater detail, including a description of the 
asset, the user can "drill down" by clicking on link 132 to 
reach Figure 6. Screen output 152 further illustrates an "Add 
Maintenance Item" button 15 8, an Edit* button 160, a Delete 
button 162, a plurality of radio buttons 164 and links 166, 
and 167 . 

[0078] For assets being tracked and managed by way of system 28, 
maintenance history items, such as those illustrated as 
"Preventive Maintenance" and "Steering Mechanism" , are 
automatically entered and available to electronic system 2 0 
through an information transfer, from a tracking system 28. 
For assets not tracked by system 28, such data is input to 
system 20 through "front-end" entry by the user (e.g., 
selecting the "Add Maintenance Item" button 158) . 
[0079] The Edit button 160, and the Delete button 162, when 
selected by the user, cause current fleet module 52 to allow 
the user to either edit, or delete, respectively, the 
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maintenance item selected via one of the radio buttons 164. 
The foregoing availability of asset specification data, 
including maintenance history data, enhances real time 
management of assets in a fleet (e.g., provides the ability to 
identify high maintenance items) . 

[0080] The user, by selecting or "clicking" on link 166, is 
provided with even greater detail for a selected maintenance 
item, for example, the item captioned "Preventive 
Maintenance" . Selecting link 167 causes current fleet module 
52 to retrieve an image of the selected asset. Other " features 
may be provided in the asset description shown in Figure 6, 
including links to asset specification information provided by 
the manufacturer, user manuals, repair manuals, and many other 
types of information that may be useful concerning the asset. 
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Virtual Rental Fleet 

[0081] Referring now to Figure 7, in accordance with the present 
invention, electronic system 20 is configured to facilitate 
transactions where a first user, such as a dealer, can consign 
assets, such as forklifts, to the electronic market 
established by system 20 for sale, rental, or lease. This 
feature allows the first user, such as the dealer, to increase 
asset utilization by exposure of the asset to a broader 
audience than just the end-user customers of that dealer. 
Additionally, by making assets available that a second 
user/dealer can rent, with a view towards sub-renting to an 
end-user customer, electronic system 2 0 in-effect provides a 
"virtual" rental fleet. The rental fleet is "virtual" because 
electronic system 2 0 enables the second user/dealer to provide 
equipment to his end-user customer that he does not own. 
[0082] Significantly, the availability of maintenance history 
data for an asset allows the second user/dealer to make a 
better- informed decision before renting the asset. In the 
rent/sub-rent scenario this is particularly important since 
the second user/dealer is typically responsible for the 
ongoing maintenance and service of the asset during the sub- 
rental term (i.e., the end-user customer typically does not 
pickup this responsibility during the sub-rental term) . 
[0083] Referring to Figure 7, a method of consigning an asset 
for sale, rental or lease on an electronic market includes 
several steps. These method steps will be described briefly 
as an initial matter, then in greater detail in- turn. 
[0084] Step 168 involves generating asset specification data 
including maintenance history data from input data provided by 
a first user. 
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[0085] Step 17 0 involves generating a bid definition from 
further input data from the first user. 

[0086] Step 172 involves storing the asset specification data 
and the bid definition together in an asset profile in market 
5 database 36. 

[0087] Step 174 involves searching, market database 3 6 based on 
criteria specified by a second user and displaying the asset 
profile . 

[0088] Step 176 involves receiving a selection of an asset from 
10 the second user for placement of a bid. 

[0089] Step 178 involves providing, to the second user, one or 
more of a purchase, rental or lease options, in accordance 
with the bid definition. Step 178 also includes receiving a 
bid on the asset from the second user, based on the 
15 transaction options. 

[0090] Step 18 0 involves receiving an acceptance of the bid from 
the first user. Once the bid has been accepted by the first 
user (i.e., the party "posting" the asset on the electronic 
market), bid module 60 operates to close ■ the transaction 
20 contemplated by the bid. 

[0091] Figure 8 provides greater detail of generating step 168 
(producing asset specification data) and generating step 170 
(producing bid definition) . In particular, Figure 8 
graphically shows in block form an asset profile 182 
25 comprising asset specification data 154, and a bid definition 
184. Referring to the upper half of Figure 8, asset 
specification data 154 includes a plurality of field values, 
including maintenance history data 156. Maintenance history 
data 156, in turn, comprises at least a date parameter 186, 
30 and an action 188 may be any of the information referred to 
above regarding the maintenance item. In the illustrated 
embodiment, generating the asset specification data may be 
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performed by executing the "add asset" method described and 
illustrated in connection with Figure 5. 

[0092] Bid definition 184 defines the parameters associated with 
the asset being consigned for sale, rental or lease to the 
electronic market created by system 20. The bid definition 
184 defines the bounds of the sale, rental or lease 
transaction involving the asset. Bid definition module 64 
(best shown in Figure 2) is configured to generate the bid 
definition 184 as follows. In one embodiment, bid definition 
module 64, when invoked by the user, prompts the user for a 
bid date 190, an availability date 192, and information 
defining the classes of users allowed to bid on the asset 194. 
The bid date 190 establishes the date when the asset is 
available for other users to bid on. The availability date 
192 defines the date when the asset can be delivered. 
[0093] Classes of users 194 include a dealer class 196, and a 
member class 198. With respect to dealer class 196, a logical 
variable 200 is associated therewith, and may take either of 
the values "Y" , indicating that dealers are allowed to bid on 
the asset, or "N" , indicating that the dealers are not allowed 
to bid on the asset. As illustrated, logical variable 200 is 
a "Y" , indicating that dealers may bid on the asset. 
Likewise, with respect to member class 198, a logical variable 
202 is provided, and may also assume one of the values "Y" or 
W N" . In the illustrated embodiment , users who are in the 
member class may also bid on the asset. It should be 
understood that other logical arrangements, such as the use of 
a logical "0" or logical w l" could also be used, being an 
equivalent thereof. 

[0094] Bid definition 184 also includes, for each class of 
users, an identification of which of a sale, rental, or lease 
transaction is available to that class of user. As shown in 
Figure 8, all three of a buy option 204, a lease option 206, 
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and a rental option 208 are enabled for both classes of users 
(e.g., members and dealers) . This is shown by a- logical 
variable 210, (which are all set to "Y" ) . For each 
transaction type available to a user class, respective 
transaction characteristic data is obtained from the first 
user. For example, the transaction characteristic data for a 
sales transaction includes a list sales price, such as shown 
in column 214, and a minimum sales price that a second user 
(e.g., another dealer) must submit to define a valid bid, such 
as shown in column 212. The transaction characteristic data 
for a rental transaction includes a list rental price for a 
predetermined period of time (e.g., a month), and a minimum 
rental price for that predetermined period of time that the 
second user must submit in order to define a valid bid. 
Finally, the transaction characteristic data for a lease 
transaction includes a total lease amount, and a term. 
[0095] In a constructed embodiment, the bid definition module 64 
executes a bid definition wizard. The information obtained 
from the first user to populate the fields described above is 
obtained through a step-by-step process, which leads the user 
along, allowing the user to click on checkboxes to select the 
classes of users who will be allowed to bid, as well as what 
respective transactions will be available to that class of 
user. In addition, the bid definition wizard, as executed by 
25 bid definition module 64, allows direct entry of dates, and 
pricing, where appropriate. 

[0096] Bid definition module 64 is also configured for storing 
the asset specification data and the bid definition in an 
asset profile in a market database 3 6 when all the needed bid 
definition information has been collected. This is shown in 
Figure 8 by a double arrowhead line to database 36. 
[0097] Having described what bid definition 184 is, and how bid 
definition module 64 operates to obtain such information, a 
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description of the user's interaction with system 20 will now 
be set forth. ■ To promote the greatest amount of flexibility 
for the user, electronic system 20 includes an asset 
configuration unit for preparing assets for posting and 
consignment. The asset configuration unit obtains the asset 
specification data and bid definition to form the asset 
profile, and comprises multiple interfaces/modules. These 
interfaces/modules include a create and define feature of 
market module 56, a sequence of the add-asset feature of. fleet 
module 48 and the add-to-market feature of fleet search module 
54, and the add-to-market feature of fleet search module 54 
(for existing assets and shown in Figure 2) . These three 
approaches will be described in detail in- turn. 
[0098] First, in a create and define feature, the asset 
specification data (including maintenance history data) , as 
well as the bid definition are made by the first user directly 
out of market module 56. That is, when a first user, such as 
a dealer, wishes to post a piece of equipment on the 
electronic market, the first user, after logging in, initially 
selects the "STORE" button 88 (Figure 3) from the user's start 
page 66, which invokes market module 56. Market module 56, as 
one of its available functions, would directly allow 
configuration of an asset (i.e., input of asset specification 
data including maintenance history data, as well as the bid 
definition) . When completed, the asset is stored in the 
market database. 

[0099] Second, if the user wishes to post an asset on the 
electronic market, but the asset does not presently 
"electrically" exist in one of the user's fleets, then the 
user can follow the "add asset" process described above in 
connection with Figure 5. Once the asset is created 
"electrically" , the user then "clicks" the "Add to Market" 
button. 
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[00100] Third, existing assets may be configured for posting 

as follows. A user, for example a dealer, who wishes to post 
the existing asset in market database 36, would invoke the 
fleet search module 54 by selecting the Search button 82. 
found on start page 66 (Figure 3) . Figure 9 illustrates a 
search form that allows the user to search the user's fleets 
to identify assets based on specified search criteria. An 
identification of assets satisfying the criteria is returned 
by fleet search module 54. The user then selects the asset to 
be placed on the market. As shown in Figure 9, this selection 
is done by selecting one of the radio buttons adjacent the 
desired asset, and then "clicking" the "Add to Market" button 
215. Since the asset specification data for the selected 
asset is already stored in the fleet database 40, only bid 
definition 184 need be generated for the asset to prepare it 
for posting. "Clicking" on the "Add to Market" button 215 
invokes the bid definition wizard, described above in 
connection with Figure 8. 

[00101] Through the foregoing functionality, electronic 

system 20 allows a user, such as a dealer, to consign an asset 
to an electronic market for rental, lease, and/or sale by a 
second user, such as another dealer. This functionality 
enables the first dealer to increase utilization of 
infrequently used pieces of equipment by making those pieces 
of equipment available to a larger audience of dealers and 
end-user customers. In addition, the second dealer realizes 
an increased virtual inventory of equipment from which to, 
preferably, rent (with a view towards sub- renting to an end- 
user customer) . 

[00102] In an alternative use of system 20, a non-dealer 

user of system 20, for example, an equipment leasing company, 
may purchase infrequently used equipment, for example, and 
make such equipment available through market database 36. The 
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universe of dealers (with the dealers sub-renting the . 
equipment to .end-user customers) and end-users may have a 
sufficiently high aggregate need for such piece of equipment 
to justify the purchase and ongoing rental to third parties. 
In this embodiment, the end-user customer need not be aware of 
the actual ownership of the equipment, and will look to the 
dealer for service, maintenance and the like. 



End-of -Lease Disposal 

[00103] A particular business type of user who may take 

particular advantage of electronic system 2 0 is one engaged in 
the business of financing the capital requirements of other 
companies. For example, such financing may involve the lease 
or rental of forklifts 22i, .., 22n to the company who 
actually uses the forklifts in its business, and who pays a 
lease or rental fee. This type of user often has a large 
number of leases that may represent literally thousands of 
individual assets that are or will periodically be coming off 
of lease. Since this type of user has no direct use for such 
assets, such assets must be disposed of in an effective 
manner. The assignee of the present invention has determined ■ 
that the information acquired during the tracking and 
management of the asset while the asset was being leased can 
be leveraged into a value proposition when such asset comes 
off of lease and must be disposed of. In particular, the 
assignee of the present invention has determined that keeping 
maintenance history data associated with assets on lease 
becomes a value-added feature when disposing of the asset in a 
fashion to be described in detail now. 

[00104] Figure 10 shows a market-search parameter input form 

216 generated by market search module 58 configured to allow a 
search of market database 36. Assets that have been tracked 
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and managed by tracking and management system 28 over an 
operating life (or portion thereof) have, associated therewith 
a substantial amount of valuable information, including 
maintenance history data. When such assets come off of lease, 
5 the particular type of user described above (i.e., lessor) 

transfers these assets into market database 36. Each asset in 
market database 3 6 has an associated asset profile comprising 
both asset specification data (including maintenance history 
data) and a bid definition. Accordingly, since these end-of- 
10 lease assets already have the asset specification data 
defined, only a bid definition needs to be created. 
Completing the bid definition may be done manually for each 
asset, or may be automated through the use of a knowledgebase 
developed over time. Once the asset profiles for the end-of- 
15 lease assets are stored in market database 36, then the other- 
users of electronic system 20 will be able to electronically 
search the market database, based on search parameters they 
specify, in anticipation of a purchase, rental or lease 
transaction. 

20 [00105] Referring to Figure 10, once such a user invokes 

market search module 58, search parameter input form 216 is 
displayed. Included in display 216 is a series of radio 
buttons: a lease radio button 218, a buy radio button 220, a 
rent radio button 222, and an "All" radio button 224. As 
25 illustrated, the lease radio button 218 has been selected; 
accordingly, all assets in market database 3 6 that are 
available for lease, and satisfy the other search parameters, 
will be identified and returned in an output display, shown in 
Figure 11. It should be understood that the search results 
30 may be further limited based on the other search parameters 
like the class of user conducting the market search (e.g., 
whether the user is a "member" or "dealer" , and whether a 
particular asset has been configured to be bid on by a 
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"member" or "dealer") . Selecting the "All" radio button 224 - 
results in a search that identifies all assets (i.e., not 
limited to any one transaction type) . Figure 10 also shows 
that a market search may be limited by a lower list price 226, 
5 an upper list price 228, as well as a plurality of further 

parameters, such as asset type, make/model, condition, year of 
manufacture, and availability date, as also illustrated. Once 
the user has defined the search, the market search is invoked 
by "clicking" the Search button 230. 
10 [00106] Figure 11 shows a screen output 232 of market search 

module 58. Output 232 includes an identification 234 of the 
assets satisfying the search parameters. In the illustrated 
embodiment, identification 234 includes a date available 
parameter, an asset description parameter, a make and model 
15 parameter, a capacity parameter, a year of manufacture 

parameter, a usage rating parameter, and a status parameter. 
The status data in the status parameter column, if any, is 
indicative of whether or not the asset has been sold. As 
shown in Figure 11, status data 235 for the "Allegany Mega-8" 
20 asset indicates that it has been sold. Importantly, each 

asset, in an illustrated embodiment, is linked to a respective 
description, detailed in nature and which includes information 
beyond that contained in the simple identification. A user 
can "click" on the "Allegany Mega-8" wording that is 
25 underlined, and will be hyper-linked to its detailed 

description. Although not shown in Figure 11, the detailed 
description of an asset may be substantially identical to the 
information illustrated in Figure 6 . 

[00107] Screen output 232 further includes a Bid button 23 6, 

30 a plurality of radio selection buttons 238, a "New Search" 

button 240, and an "Add to Fantasy Fleet" button 242 having an 
associated pull down menu 244. Bid module 60 is configured to 
allow the user to select one of the assets identified in the 
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market* search for placement of a bid. To place- a bid on an- 
asset, the user first selects the asset using the radio 
buttons 238. Thereafter, the user "clicks" on Bid button 236, 
which invokes bid module 60. The Move or Add to fantasy fleet 
button 242 will be described in greater detail below in 
connection with the simulated fleet feature of the present 
invention . 

[00108] Figure 12 shows a screen output 24 5 generated by bid 

module 60. In a constructed embodiment, output 245 includes 
the detailed description of the asset, similar to Figure 6, 
but which has been omitted from Figure 12 for clarity. Bid 
module 60 provides transaction options: a purchase transaction 
option 246, a lease transaction option 248, and a rental 
transaction option 250. The desired transaction is selected 
by the user through the radio buttons. In the illustrated 
embodiment, a "Buy" transaction has been selected by the user. 
[00109] When the selected transaction is a purchase 

transaction, bid module 60 is configured to prompt the user 
for a bid price offered for the selected asset, which is 
entered in input box 252. As used herein, the wording 
"prompt" merely means to provide a mechanism or means to 
accept the bid price, and does not suggest or require some 
active activity, such as a blinking input box, input wizard or 
the like. 

[00110] When the selected transaction is a lease 

transaction, bid module 60 is further configured to prompt the 
user to select a lease term, a lease type, and a monthly lease 
amount offered for the selected asset. As illustrated in 
exemplary fashion in Figure 12, the lease term may be input 
through a pull down menu 254, the lease type may be input 
through pull down menu 256, and the monthly lease amount may 
be entered (e.g., keyboard) in box 258. In a constructed 
embodiment, the lease term may be one of a 24 -month, 3 6 month, 
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4 8 month, 6 0 month, and 72 month term. Further, in a 
constructed embodiment,, the lease type may be one of a 
category 1, category 2, category 3, fixed-ten (10%) percent, 
fixed-twenty percent (20%) , buyout-new, buyout-used, category 
5 4, category 5, category 6, and category 7 type leases. Lease 
types may be totally configurable. Of course, other options 
may be used or offered to the user, depending on the asset, 
market conditions, etc. To facilitate the bidding process, 
bid module 60 further includes a lease calculator tool, which 
10 may be invoked by "clicking" on the Lease Calculator button 
262. The lease calculator tool allows the user to specify 
lease term and lease type, and enter a third parameter, either 
a monthly payment or a total lease amount, and have the lease 
calculator calculate a fourth parameter, the other one of the 
15 lease amount and monthly payment. The calculated amount can 
be directly transferred to the monthly lease amount box 258. 
[00111] When the selected transaction is a rental 

transaction, bid module 60 is further configured to prompt the 
user for a monthly rental price offered for the selected 
20 asset, which may be entered in box 260. The user may submit 
the bid by "clicking" on the "Submit Bid" button 264. 
[00112] Bid module 60 is further configured to generate a 

bid history (not shown) for each asset that has been posted in 
market database 36. The bid history comprises a listing of 
25 each bid made by the users of system 2 0 on a particular asset. 
The bid history includes a detail of the submitted bid (e.g., 
by whom, price offered, etc.) . Bid module 60 is also ■ 
configured to allow the user that posts the asset in the 
market database (e.g., the leasing company), to retrieve the 
30 bid history, to review the bids contained in the listing, and 
finally to accept one of the bids to thereby complete the 
offered transaction. 
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[00113] Through the foregoing, accumulated information 

acquired from the tracking and managing of assets can be 
leveraged to increase financial return when such assets come 
off of lease and must be disposed of.' 
5 [00114] In some cases, it is desirable to have a subsystem 

3 00 that runs on a periodic basis, which compares a subset of 
all assets 22 within system 20 with a series of pre-defined 
conditions 302 to determine if an action needs to be taken 
with respect to asset disposition. The pre-defined conditions 

10 include either a time variable or a cost variable. For 

example, one condition using a time variable involves the 
natural end of an asset lease - including, for example a set 
time period such as six (6) months prior to an end of a lease. 
Thus, the time variable is associated with the passage of 

15 time. A second condition using a time variable includes a 

situation such as when a particular asset has excessive usage 
compared to its time (e.g., hours) in service. An example 
condition using a cost variable involves an over usage of an 
asset, wherein based on such over usage, penalties begin to be 

20 invoked. Another example condition using a cost variable 
results when an analysis shows that the cost of leasing an 
asset appears to be higher than a threshold level when 
compared to other asset usage options that are immediately 
available to the asset user (e.g., a lessee) such as by 

25 purchasing more assets at a lower cost or reallocating 

existing assets between locations. It is also possible to 
develop pre-defined conditions using a combination of time and 
cost variables. For example, an excessive usage criteria may 
involve both a time element and a cost element. 
30 [00115] As illustrated in Figure 15, if no pre-defined 

conditions are met at point 3 02 subsystem 3 00 terminates at 
point 304. Alternatively, if a condition is met, subsystem 
3 00 proposes a hierarchy of options at point 30 6 as to a 
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proposed action for the benefit of the asset user such as a 
lessee. The data for making the various options comes from 
market database 36, global asset database 38,, fleet database 
40 or asset database 42. As noted above, these may actually 
5 be one or more separate databases. Typically, the information 
used to determine the pre-defined conditions and available 
options comes from asset identification data, maintenance 
history data, and lease term. The identification data 
includes asset make/model and serial number. Lease term may 
10 be determined by an analysis of at least two of three pieces 
of data, namely, lease start date, lease end date, and the 
length of time between the lease start and end dates. 
[00116] Possible options based on pre-defined conditions 

include: the leasing of additional assets to reduce the amount 
15 of use of a pre-existing asset; a comparison of a cost of. 
leasing an asset with a threshold level representing lower 
cost alternatives; the leasing of additional assets; asset 
lease renewal; asset purchase or buyout; asset disposal; asset 
sale; or asset sale and purchase of replacement assets. 
20 Associated with each option is the cost of invoking the option 
and the reasons why the system, in accordance with its review 
of each option in accordance with the pre-defined rules, 
believes that the selected hierarchy of options is preferred. 
Most often the controlling factor will be total price to the 
25 asset user for the collection of assets performing the same or 
similar function, 

[00117] Before suggesting lease renewal, for example, the 

system preferably reviews a database of historical information 
about lease considerations involving similar assets and 
30 alternatively consults with other lessor representatives to 

determine a quote for renewing the lease term. If this price 
is lower than other options, it will be listed first. 
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[00118] Before suggesting the leasing of additional assets,, 

the system preferably reviews current pricing information and 
asset availability. If the system determines that the overall 
cost to the asset user will decrease the most if this option 
5 is selected, then it will be listed first 

[00119] In the case of buyout, subsystem 3 00 may review any 

existing contract language between the lessor and lessee 
concerning a fixed price. If there is no such price, it may 
then review historical information concerning buyouts 
10 involving similar assets potentially taking into account such 
things as asset condition and usage patterns to make a 
recommendation . 

[00120] Finally, before suggesting lease disposal, subsystem 

300 considers the cost, if any, with disposing of an asset 22, 
15 so that the information may be provided to the; asset user. 
[00121] Once subsystem 300 determines the hierarchy of 

possible options to send to an asset user concerning an asset 
at point 306, notification is sent to an account manager of 
the lessor having a relationship with the asset user. The 
20 account manager is given a report 3 08 that includes each asset 
meeting the pre-defined condition and a link to specific 
information about the asset including asset description, 
utilization, maintenance history and costs. If there are a 
number of assets/ the assets may be grouped by asset type, 

25 time until lease termination, cost, usage, lessee company, 
asset location, or any other desired criteria. A group 
manager, to whom an account manager reports, may see assets 
associated with each account manager. The group manager can 
sort assets in any manner available to an account manager, but 

30 has the additional capability to sort assets in accordance 
with each account manager. 
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[00122] In general, the account manager will review one or 

more of the proposed options generated by subsystem 302 to . 
confirm his agreement with both the hierarchy and the 
specifics of each option as shown by point 310. 

Alternatively, the account manager may just review the present 
option to confirm his agreement with the specific proposal. 
In some cases it may be desirable to bypass the account 
manager to have it sent directly to the asset user. However, 
in many cases, minor adjustments may be appropriate before the 
option details are transmitted to the asset user. Depending 
on the nature of the refinements, however, it may be desirable 
to refine the pre-defined rules in general or for a particular 
asset user if the nature of the refinement represents 
particular preferences of such a user. For example, a 
particular customer may never wish to buy an asset 22 under 
any circumstances so an option related to a buyout should 
never be presented to that customer. Thus, in a preferred 
embodiment of the invention, the proposed options are manually 
reviewed, and in the case where modifications are made, the 
rational for the modifications are incorporated back into 
subsystem 300. Thus, a rejection of a hierarchy of options 
generates feedback for selectively modifying the availability 
of future options by system 3 00 at either a global or customer 
level . 

[00123] Once the option hierarchy is finalized, the options 

are sent in descending order of expected acceptance, as 
discussed in more detail below, to an asset user by way of 
electronic mail, facsimile, regular mail, or even a link 
available on a web site accessible to the asset user. Two-way 
electronic communications with simple pre-programmed responses 
available to the asset user are preferred since no manual 
updating of subsystem 300 is then required. 
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[00124] Figure 16 illustrates an example of a report 308 in 

the form of an- interactive screen available to the account 
manager or group manager with various columns. Typically, 
report 3 08 is accessed using a client computer 24 and web 
server 30, as discussed above. Column 312 shows a listing of 
various lessee companies. Column 314, which is broken into 
three sub-columns, relates to end of lease options. The first 
sub-column gives the months remaining before an option must be 
selected while the second sub-column gives the actual deadline 
date. The third sub-column is a hyperlink, which when 
clicked, gives detail on the various options available and 
their hierarchy, as well as specific lease related details 
such as pricing or proposed lease term. The detail can be 
optionally- edited, subject to any internal lessor approval 
process. Column 316 gives facility information. Broken into 
two sub-columns, the first sub-column gives city and state 
information while the detail information associated with asset 
22 and its location is accessible by the hyperlink of the 
second sub-column. Column 318 includes the asset information 
in sub- column format such as asset make, model and serial 
number. More complete information including full maintenance 
history, lease information, and the like is available by way 
of the detail hyperlink. Finally, column 320 gives the status 
of various communications sent or received from an asset user. 
Communication status 320 represents the nature of all 
communications sent or received back from an asset user and 
the option currently pending from the hierarchical list of 
options available for the particular situation. A response by 
the asset user triggers automatically the next response by 
subsystem 300 for the particular asset as discussed by way of 
example below. 

[00125] In Figure 16, assets 22 are listed individually by 

each row, but also sorted by lessee company. In the present 
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example, assets 22 meeting a pre-defined condition associated 
with companies EOF and Zen's are activated for review. 
[00126] It is also possible for a specific lessee to see a 

similar screen if accessing the information by way of a client 
computer 24 and web server 30. However, in such a case, the 
information would be limited to leases associated with the 
particular lessee organization. It also facilitates follow up 
between an asset user and a lessor to avoid undesirable delay 
in determining what to do with an asset . 

[00127] If an asset user rejects a particular recommendation 

as shown by a change in communication status, the next best 
option is then presented to the account manager for review and 
transmission to an asset user until a decision is made. 
[00128] In the example of Figure 15, the option of accepting 

a new lease involving new asset is first recommended to the 
account manager at point 322. Typically, this is called "New 
Item" in column 320. If the account manager agrees with the 
proposed terms including cost and duration, he sends it to the 
asset user. Column 320 is updated to reflect "New Item Sent". 
If the asset user accepts it ("Customer Accepts New Lease" in 
column) at point 324, then a new asset is delivered to the 
asset user at point 326, the off -leased asset is picked up and 
moved to storage for re-sale or re-lease to a different party 
at point 328. Subsystem 3 00 then forks to point 390, where 
system 20 is updated with the data related to the assets at 
point 3 92 and terminates at point 3 94. 

[00129] If the asset user rejects the new lease option 

("Customer Declines New Lease" in column 320) at decision 
point 3 24, then the subsystem 300 recommends based on the next 
most- favorable option, in this example that the asset user 
renews its lease of the asset ("Renew Lease" in column 320) , 
which the account manager reviews in the form of an updated 
report at point 332. If he agrees with the proposed terms 
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including cost and duration/ then it is sent to the asset" user 
* ("Renew Lease Sent" in column 320) . If the asset user accepts 
this option ("Customer Accepts Renewal" in column 32 0) at 
decision point 334, then renewal documentation is sent to the 
5 asset user at point 336 with subsystem 300 forking to point 
390 as above. If the asset user rejects the second option 
("Customer Declines Renewal" in column 320) , subsystem 3 00 
then suggests to the account manager that there be a buy out 
of the asset by the asset user ("Buyout"), which is reviewed 

10 at point 338. Once again, if the account manager agrees, the 
option with relevant detail on the terms of the proposed 
buyout is sent to the asset user ("Buyout Option Sent" in 
column 320) . If the asset user accepts that option ("Customer 
Accepts Buyout") at decision point 340 and the generated 

15 buyout price, then the asset is sold to the asset user as 

shown by point 342 with the subsystem forking to point 390. 
[00130] Finally, if the asset user does not accept any of 

the prior options at point 340, then subsystem 300 sends out a 
request to the asset user concerning when the asset should be 

20 picked up ("Pickup Timing Sent" in column 320) at point 344, 
and the asset is picked up at point 346 at the time and 
location agreed to at point 344. with subsystem 300 forking to 
point 3 90. 

[00131] No interaction by the account manager is required 

25 once all of the remaining options have been provided. In this 
example, subsystem 3 00 determined that the addition of assets 
22 while maintaining the existing asset was not a viable 
option, so it was not presented for consideration. 
[00132] While Figure 15 exemplifies one possible course of 

30 conduct between a- lessor and lessee with respect to a 

particular asset 22, the actual hierarchy of options will 
depend on the asset, characteristics of the asset user (e.g., 
e.g., a local versus a national company) current market 
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10 



conditions (e.g., asset availability on the open market-, and 
pricing), and the nature of the relationship between lessee 
and lessor (e.g., the existence of any particular preferred 
arrangement for the benefit of the asset user) . Further, even 
after an asset user agrees to an option, further negotiation 
as to cost and lease timing may be required. For example, as 
shown in Figure. 16, column 320 shows additional status 
entries: "New Quote Sent", "New Quote Returned" and "Quote 
Accepted", reflecting additional level of detail available as 
part of the operation of subsystem 300. 
[00133] In summary, subsystem 300 works as follows. A 

database is configured and information associated with a 
plurality of assets 22 is stored in the database. Subsystem 
3 00 analyzes the information in accordance with a set of pre- 
15 defined conditions. When a pre-defined condition is met, the 
subsystem recommends asset disposition using a hierarchy of 
disposition options, and the conditions and the options are 
selected to reduce expense and to maximize the return on 
investment for the asset user. The hierarchy of options are 
typically manually checked and confirmed, and a rejection of 
the hierarchy of options generates feedback with the system 
modifying as appropriate the availability of future options. 
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Simulated ("Fantasy") Fleet 

25 

[00134] Conventional asset management systems lack effective 

tools for conducting "what if" analyses i.e., modeling a 
simulated fleet containing both actual assets and proposed 
assets. The invention overcomes the shortcomings inherent in 
30 conventional systems by providing an electronic system 20 for 
modeling a simulated fleet. For example, if two older 
machines, each with high maintenance costs, are replaced by 
two newer machines with lower maintenance costs, but with 
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higher lease costs, what effect would such a change make on 
the overall performance of the fleet? The Fantasy Fleet 
simulator of the present invention enables computer-based 
modeling that assists answering such questions. 

[00135] As shown in Figure 3, a Fantasy Fleet may be created 

in the same manner as an actual fleet (a fleet with real 
assets). A fantasy fleet may be created by "clicking" on a 
Create button 108, which invokes the simulated fleet module 
.5 0, which in turn prompts the user to input a fantasy fleet 
name, as well as a location. Once the fantasy fleet has been 
created, assets may then be added. 

[00136] To promote the greatest amount of flexibility 

possible, electronic system 20, to implement the "Fantasy" 
fleet feature, includes a simulated fleet configuration unit 
that comprises multiple interfaces/modules for setting up and 
adding assets, to the fantasy fleet. These interfaces/modules 
include at least one of an add-asset feature of simulated 
fleet module 50, an add-to fleet feature via the fleet search 
module 54, an add-to-fleet feature via market search module 
58, and a step-by-step entry system of the fleet builder 
module (not shown) , accessible via the "Fleet Builder" button 
on the user's start page 66. Each will be described in turn. 
[00137] First, the add-asset feature of simulated fleet 

module 50 may be used. A user may "click" on link 116 in 
Figure 3, which causes simulated fleet module 50 to generate a 
screen output 266 --an asset view-- as shown in Figure 13. 
The user interface illustrated in Figure 13 operates in 
substantially the same manner as the user interface 
illustrated in Figure 4 for assets contained in an existing 
fleet. For example, the user, by "clicking" on the "Add- 
Asset" button 268, causes simulated fleet module 50 to present 
an input data dialog, in accordance with the flowchart of 
Figure 5, for adding an asset. The user then configures the 
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asset in the same manner as described above for an existing 
fleet. 

[00138] Second, the add-to-fleet feature of fleet search 

module 54 may be used. As shown in Figure 9, a user can 
5 search his fleets by selecting search button 82 from the 

user's start page 66 (Figure 3), which invokes fleet search 
module 54 . The search results contain an identification of 
the assets that are available for selection. Selection may 
occur, for example, through the use of radio buttons, as shown 
10 in Figure 9. The user may then select a destination-simulated 
fleet through the use of pull down menu 270, and then add the 
chosen asset to the desired fantasy fleet by "clicking" on Add 
button 2 72 . 

[00139] Third, the add-to-fleet feature of .market search 

15 module 58 may be used. The further method for adding assets 
to a fantasy fleet involves conducting a market search, using 
market search module 56, as illustrated in Figure 10. Then, 
the user adds assets by selecting the desired destination 
fantasy fleet through pull down menu 244, and "clicking" on 

20 the Add button 242. Through this approach, items available in 
market database 3 6 may be added to the fantasy fleet. 
[00140] Fourth, a user may use the fleet builder wizard to 

create a fantasy fleet and configure and add assets. The 
fleet builder wizard may be invoked by "clicking" on the 

25 "Fleet Builder" button 86 on the user's start page 66. This 
step-by- step entry system leads the user along, prompting for 
a fleet name, and location, an indication that it is a fantasy 
fleet, and prompts to add an asset. The add asset feature of 
the "fleet builder" dialog is substantially the same as the 

30 "add asset" feature of the current fleet module 52, described 
above (e.g., Figure 5) . 

[00141] Figure 14 shows a report 274 generated by reporting 

and analysis module 62 . In particul ar , each asset listed in 
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the report has an associated plurality of parameters, such as 
average monthly usage hours, total maintenance cost, hourly 
maintenance cost, total lease cost, total operating cost, 
total hourly cost, percent utilization, etc. A user can 
5 invoke the reporting and analysis module 62 by selecting the 
Reporting button 92 from the "start" page 66 shown in Figure 
3. The user may then select the target fleet (existing or 
fantasy) for which the report (s) will be generated. A user 
can evaluate changes made to an existing fleet by generating a 
10 report for an existing fleet, configuring a simulated fleet ' 
reflecting the proposed changes, and then generating a second 
report. 

[00142] The two reports can be compared and decisions made 

based on the results of the comparison. In the report shown 
15 in Figure 14, the assets enclosed by dashed- line box 276 are 
part of an existing fleet for which a report (not shown) has 
already been or will be generated by module 62. The assets 
shown in dashed- line box 278 are proposed additions to the 
existing fleet. The combination of the assets in dashed-line 
20 box 276, and dashed-line box 278 constitute the simulated or 
fantasy fleet. One exemplary parameter is total hourly cost 
280. Reporting and analysis module 62 is configured to 
generate report 274 having a composite output 282 that is 
characteristic of all the assets in the simulated fleet. The 
25 composite total hourly cost 2 82 can then be compared to the 

corresponding total hourly cost for the existing fleet (in the 
other report) to make an evaluation of the proposed changes. 
Another composite output shown in Figure 14 is percent 
utilization 284. It should be appreciated that some of the 
30 composite parameter values are determined by reporting and 

analyzing module 62 according to an arithmetic sum function, 
such as the total maintenance cost parameter. Reporting and 
analyzing module 62 is further configured to determine other 
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composite parameters, such as hourly maintenance- cost, 
utilization, and total hourly cost, according to an arithmetic 
average function. The parameters dealing with money amounts 
(e.g., dollars) required or desirable to make an asset 
acquisition determination may be characterized as a financial 
figure of merit. Other parameters, such as utilization 
percent, may be characterized as a performance figure of 
merit . 

[00143] To the extent that the specific assets included in 

the simulated fleet have actual usage, performance, 
utilization, and cost data associated therewith, then such 
information is used by reporting and analyzing module 62 in 
computing composite values. However, when the assets are of 
the type that have no asset -specific data associated 
therewith, then profiled asset specification data is used in 
performing the analysis. Additionally, when preconf igured 
assets from preconf igured database 42 are included in a 
simulated fleet (or in an actual fleet) , then composite data 
for assets of a similar type are used by module 62 for 
analysis purposes. 

[00144] In accordance with the provisions of the patent 

statutes, the principle and mode of operation of this 
invention have been explained and illustrated in several 
preferred embodiments. However, it must be understood that 
this invention may be practiced otherwise than as specifically 
explained and illustrated without departing from its spirit 
and scope . 
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CLAIMS 

What is claimed is:. 

1. An electronic system for facilitating disposition of 
an asset currently under lease by an asset user, comprising: 

at least one database configured to store 
information associated with a plurality of assets ; 

a set of pre-defined conditions related to a 
recommendation of asset disposition based on an automated 
analysis of said information within said system, at least one 
of said conditions being met; and 

a hierarchy of disposition options generated by said 
system based on said at least one of said conditions, wherein 
said conditions and said options are chosen to reduce expense 
by maximizing return on investment to the asset user. 

2. An electronic system as recited in claim 1, wherein 
said pre-defined conditions include at least one of a time 
variable and a cost variable. 

3. An electronic system as recited in claim 2, wherein 
said time variable comprises a passage of time, said at least 
one of said conditions being met when an asset approaches the 
end of a lease term. 

4. An electronic system as recited in claim 3, wherein 
said options include lease renewal; asset buyout; and asset 
return. 
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5. An electronic system as recited in claim 3, wherein 
said time variable comprises asset usage within a 
predetermined period of time, said at least one of said 
conditions being met when asset use exceeds a usage criteria 
based on time in service. 

6. An electronic system as recited in claim 5, wherein 
said options include the leasing of additional assets to 
reduce the amount of use of a pre-existing asset. 

7. An electronic system as recited in claim 2, wherein 
said cost variable includes a comparison of a cost of leasing 
an asset with a threshold level representing lower cost 
alternatives. 

8. An electronic system as recited in claim 7, wherein 
said options include the leasing of additional assets. 

9. An electronic system as recited in claim 1, wherein 
said information includes asset identification data, 
maintenance history data, and lease term. 

10. An electronic system as recited in claim 9, wherein 
said identification data comprises an asset make/model and 
serial number. 

11. An electronic system as recited in claim 9, wherein 
said lease term includes at least two of a lease start date, a 
lease termination date, and a length of time between said 
lease start date and said lease termination date. 
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12. An electronic system as recited in claim. 1, further 
comprising a manual check and confirmation of said hierarchy 
of options, wherein a rejection of said hierarchy generates 
feedback selectively modifying said availability of future 
options by said system. 

13. An electronic system as recited in claim 1, wherein 
said options are presented to the asset user for consideration 
in order of expected acceptance. 

14. An electronic system as recited in claim 1, wherein 
one of said options is a new lease, wherein upon acceptance of 
said new lease, a new asset is delivered to the asset user, an 
off-leased asset is picked up, and said off-leased asset is 
disposed. 

15. An electronic system as recited in claim 1, wherein 
one of said options is a renewed lease, wherein upon 
acceptance of said renewed lease renewal documents are 
executed by the asset user. 

16. An electronic system as recited in claim 1, wherein 
one of said options is an asset buyout, wherein upon 
acceptance of said asset buyout, the asset is purchased. 
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17. "'An electronic system for facilitating disposition of 
an asset currently under" lease by an asset user, comprising: - 

at least one database configured to store 
information associated with a plurality of assets; 

a set of pre-defined conditions related to a 
recommendation of asset disposition based on an automated 
analysis of said information within said system, each of said 
conditions comprising at least one of a time variable and a 
cost variable, at least one of said conditions being met; 

a hierarchy of disposition options generated by said 
system based on said at least one of said conditions, wherein 
said conditions and said options are chosen to reduce expense 
by maximizing return on investment to the asset user,- and 

a manual check and confirmation of said hierarchy of 
options, wherein a rejection of said hierarchy generates 
feedback selectively modifying said availability of future 
options by said system. 

18. An electronic system as recited in claim 17, wherein said 
time variable comprising a passage of time, said at least one 
of said conditions being met when an asset approaches the end 
of a lease term or when asset usage exceeds a usage criteria 
based on time in service; and 

said cost viable including a comparison of a cost of 
leasing an asset with a threshold level representing lower 
cost alternatives . 
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19. An electronic system as recited in claim 17, said 
information including asset identification data, maintenance 
history data, and lease term, wherein said identification data 
comprises an asset make/model and serial number, and said 
lease term includes at least two of a lease start date, a 
i ease termination date, and a length of time between said 
lease start date and said lease termination date. 

20. An electronic system as recited in claim 17, wherein 
said options are presented to the asset user for consideration 
in order of expected acceptance, and wherein, 

a first of said options comprises a new lease such that 
upon acceptance of said new lease, a new asset is delivered to 
the asset user, an off-leased asset is picked up, and said 
off-leased asset is disposed, 

a second of said options is a renewed lease such that 
upon acceptance of said renewed lease renewal documents are 
executed by the asset user, and 

a third of said options is an asset buyout such that upon 
acceptance of said asset buyout, the asset is purchased. 
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21: A method for facilitating disposition of an ass.et 
currently under lease an asset user, comprising the steps, .of: 

configuring at least one database and storing 
information associated with a plurality of assets;. 

analyzing said information in accordance with a set 
of pre-defined conditions, each of said conditions comprising 
at least one of a time variable and a cost variable; 

meeting at least one of said pre-defined conditions; 

recommending asset disposition using a hierarchy of 
disposition options; and 

selecting said conditions and said options by 
reducing expense and maximizing return on investment to the 
asset user. 

22. A method as recited in claim 21, further 
comprising the step of: 

instituting a manual check and confirmation of said 
hierarchy of options; and 

said rejection of said hierarchy generating 
feedback, selectively modifying said availability of future 
options by said system. 
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23. An electronic system as recited in claim 21, 
including the further step presenting said hierarchy of 
options to the asset user for consideration in order of 
expected acceptance, and wherein, 

a first of said options comprises a new lease such that 
upon accepting said new lease, delivering a new asset to the 
asset user and picking up and disposing of an off-leased 
asset , 

a second of said options is a renewed lease such that 
upon accepting said renewed lease renewal, the asset user 
executing renewal documents, and 

a third of said options is an asset buyout such that upon 
accepting said asset buyout, the asset user purchases the 
asset. 
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ABSTRACT OF THE DISCLOSURE 

A database is configured and information associated with 
a plurality of assets is stored in the database. The system 
5 automatically analyzes the information in accordance with a 
set of pre-defined conditions. When a pre-defined condition 
is met, the subsystem recommends asset disposition using a 
hierarchy of disposition options, and the conditions and the 
options are selected to reduce expense and to maximise the 
10 return on investment for the asset user. The hierarchy of 

options are typically manually checked and confirmed, and a 
rejection of the hierarchy of options generates feedback with 
the system modifying as appropriate the availability of future 
options . 
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Michael B. Stewart 



To: 



Sent: 



From: 



AndyFSuhy@aoI.com 

Monday, November 26, 2001 12:32 PM 

mbs @ raderfishman.com 



Cc: BRENTPARENT@aol.com 
Subject: Patent Application 

Michael, 

This email is in response to your recent request for my signature on a Dana patent application. While you have 
provided patent application documentation, neither you nor anybody from your client Dana has made any attempt 
to contact me to discuss this issue in detail, specifically why my signature may be desired, and what risk/rewards 
are involved now that I am no longer an employee of Dana. 

I am more than willing to sign any necessary documents, but will not do so without the proper assessment and 
due diligence process. Shipping overnight via FedEx 2 inches of documents with a note saying "please sign" 
does not constitute an effort on your part to acquire my signature. After discussing this issue with Brent Parent, 
he agrees with my analysis of your request for signature process, which has thoroughly confused us both. 

Feel free to call if you would like to discuss this matter further. 

Regards, 

Andy Suhy 

419-344-7966 (mobile) 
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From: Michael B. Stewart 

Sent: Monday, November 26, 2001 1 2:46 PM 

To: 'AndyFSuhyOaol.com'; Michael B. Stewart 

Cc: BRENTPARENT@aol.com 

Subject: RE: Patent Application 

Thanks, Andy. I will give you and Brent a call to try to answer any questions you have. 

-mbs 



— Original Message 

From: AndyFSuhy@aol.com [mailto:AndyFSuhy@aol.com] 
Sent: Monday, November 26, 2001 12:32 PM 
To: mbs@raderfishman.com 
Cc: BRENTPARENT@aol.com 
Subject: Patent Application 

Michael, 

This email is in response to your recent request for my signature on a Dana patent application. 
While you have provided patent application documentation, neither you nor anybody from your client 
Dana has made any attempt to contact me to discuss this issue in detail, specifically why my 
signature may be desired, and what risk/rewards are involved now that I am no longer an employee 
of Dana. 

I am more than willing to sign any necessary documents, but will not do so without the proper 
assessment and due diligence process. Shipping overnight via FedEx 2 inches of documents with a 
note saying "please sign" does not constitute an effort on your part to acquire my signature. After 
discussing this issue with Brent Parent, he agrees with my analysis of your request for signature 
process, which has thoroughly confused us both. 

Feel free to call if you would like to discuss this matter further. 

Regards, 

Andy Suhy 

419-344-7966 (mobile) 
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RADER FISHMAN GRAUER 



2485940610 P. 02/02 
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U.S. Mai!: PO Box 727 
Memphis, TN0S194-dS43 



Telephone 501-069-3600 



Fed 



FedEx Express 
Customer Stpport 
Domestic Trfloe 
3376 Airways Boulevard 
Modde H, «h Row 
Memphis, TN 331 16 



EL 

Express 

August 22,2002 

A; ISA varela 
(248) 594-0610 

Dear A; ISA varela : 

Our records reflect the following delivery information for the shipment with the tracking number 
470263976647. The information is incomplete and we regret the inconvenience this may cause. 
However, as stated in the FedEx Service Guide, we assume no liability for our inability to provide 
a copy of the delivery record. 

Delivery Information: 

Signed For By: B. PARENT 

Delivered to: 247 STONE OAK COURT 

Delivery Date: July 20, 2002 

Delivery Time: 1 1 :39 AM 



Shipping Information: 

Shipment Reference Information: 65678-0042 

Tracking No: 470263976647 Ship Date: July 1 9, 2002 

Shipper: RADER FISHMAN GRAUER Recipient: BRENT C. PARENT 
PLLC 

39533 WOODWARD AVE STE 247 STONE OAK COU RT 

14 HOLLAND, OH 43528 

BLOOMFIELD HILLS, Ml US 

483045098 

US 



Thank you for choosing FedEx Express. We look forward to working with you in the future. 

FedEx Worldwide Customer Service 
1-800-Go-FedEx (1-800-463-3339) 
Reference No: R20Q20822Q0057 176041 

This Information is provided subject to the FedEx Service Guide. 
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Michael B. Stewart 



To: 



Sent: 



Subject: 



From: 



Michael B. Stewart 

Thursday, August 29, 2002 9:47 AM 

Michael B. Stewart; 'andyfsuhy@aol.com'; 'Brentparent@aol.com' 
RE: Application formal papers 



PIChecked: true 
PICheckedDate: 8/29/2002 9:51:17 AM 
PIMessagelD: E78242FE-DE3E-4DD4-950F-9F4C8F 

I apologize, I made a mistake with your e-mail address, Andy. Thanks. 

— Original Message 

From: Michael B. Stewart 

Sent: Thursday, August 29, 2002 9:46 AM 

To: 'adnyfsuhy@aoI.com' 

Cc: 'Brentparent@aol.com 1 

Subject: Application formal papers 

Gentlemen, we confirm that each of you received packages concerning two patent applications on July 20, 
2002. The applications were for an "Apparatus and Method for Tracking and Managing Physical 
Assets" (5397 DCCSP) and a "System and Method for Disposing of Assets" (5672 DCCSP). We note that 
that you have not responded to the letters dated July 19, 2002. Therefore, we confirm that that you 
continue to join in either application. If you have any questions or my understanding is in error, please 
contact me. Thank you. 



~mbs 



Michael B. Stewart of Rader, Fishman & Grauer PLLC 

39533 Woodward Ave., Ste. 140 Bloomfield Hills, Ml 48304 

PH: +1-248-594-0633 FAX:+1 -248-594-0610 mbs@raderfishman.com 



RADER, 



FISHIVIAIM 




39533 Woodward Ave., Ste. 140 
Bloomfield Hills, Michigan 48304 
Tel: (248) 594-0600 
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Re: U.S. Patent Application for APPARATUS AND METHOD FOR TRACKING 
AND MANAGING PHYSICAL ASSETS 
Dana Case 5397 DCCSP; Our Ref. 65678-0037 

U.S. Continuation-in-Part Patent Application for SYSTEM AND METHOD FOR 
DISPOSING OF ASSETS 

Dana Case 5672 DCCSP; Our Ref. No. 65678-0042 



Dear Andy: 

Once again, we enclose a copy of the package that we sent to you on November 16, 2001, including both 
the letter and the indicated attachments. The attachments comprise complete copies of U.S. patent applications 
for Dana reference numbers 5397 DCCSP (U.S. Application Serial No. 09/7 14,702) and 5672 DCCSP (U.S. 
Application Serial No. 09/990,91 1), the currently executed versions of combined Declaration and Power of 
Attorney for each of the applications by other co-inventors for that application, and the Declaration and Power of 
Attorney you originally executed for 5397 DCCSP. Once again we also have tabbed where you need to sign your 
name as an inventor for each of the applications on the applicable Combined Declaration and Power of Attorney 
document. 

As we both know, you in fact received the package that we sent to you on November 16, 2001 to your 
Ohio address. This letter is not being sent to the old New York Address since the package sent was returned for 
non-delivery and a confirmation written on the package that you had moved. 

You sent me an email on November 26, 2001, acknowledging receipt of the package. I responded to the 
e-mail promptly upon receipt. Further, in response to the email communication, I tried to contact you on your 
mobile telephone using the phone number you provided in your e-mail, but did not receive any return telephone 
calls. Your electronic mail communication to me was carbon copied Brent Parent. 

On November 20, 2001, Mr. Parent left me a message with both his cellular telephone number and his 
home number. Within a day or so after receiving your e-mail and responding, I spoke personally with Mr. Parent 
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by phone concerning the legal obligations that both you and he have to sign and return the Combined Declaration 
and Power of Attorney documents based on your employment with Dana Corporation at the time that the 
invention was developed by each of you as co-inventors for the indicated applications. As I also explained to Mr. 
Parent, if a joint inventor refuses to join in an application for patent cannot be found or reached after diligent 
effort, 'the application may be made by the other co-inventors on behalf of himself or herself and the non-signing 
inventor. A refusal to sign the Combined Declaration and Power of Attorney is such a refusal. 

Based on my discussions with Mr. Parent, he indicated that he would pass on the clarifications that we 
discussed of the reasons associated with the need for your signature on the enclosed papers. 

If you have any specific questions, please contact me. Otherwise, please return executed copies of the 
Combined Declaration and Power of Attorney documents for the two cases. You can keep the patent applications 
for your records. For your convenience we enclose a self-addressed and stamped Express mail envelope. All you 
have to do is to put the executed papers in the envelope and drop it in an appropriate US postal service mailbox. 

In the absence of receiving the executed Combined Declaration and Power of Attorney documents from 
you by July 29, 2002, we will be forced to conclude yet again that you will continue to refuse to sign them in 
accordance with your past efforts with respect to a number of different applications and share this refusal with the 
United States Patent and Trademark Office. 

If you have any questions, please contact me. 

Very truly yours, 
RADER, FISHMAN & GRAUER PLLC 




Michael B. Stewart 



MBS/amv 
Enc. 
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November 16, 2001 



Andrew F. Suhy, Jr. 

30 Avenue at Port Imperial #301 

West New York, NJ 07093 

Andrew F. Suhy, Jr. 
8022 North Bridge Way 
Maumee, OH 43537 

Re: U.S. Patent Application for APPARATUS AND METHOD FOR TRACKING 
AND MANAGING PHYSICAL ASSETS 
Dana Case 5397 DCCSP; Our Ref. 65678-0037 

U.S. Continuation-in-Part Patent Application for SYSTEM AND METHOD FOR 
DISPOSING OF ASSETS 

Dana Case 5672 DCCSP; Our Ref. No. 65678-0042 



Dear Andy: 

Thank you for your prior assistance in completing a Combined Declaration and Power of Attorney with 
respect to the above-identified 65678-0037 application. For your convenience, a copy of the executed Combined 
Declaration and Power of Attorney is enclosed along with a copy of the application as filed. The U.S. Patent 
Office has requested that you execute a Combined Declaration and Power of Attorney that lists all of the 
inventors Therefore, we would appreciate your assistance in executing a copy of the Combmed Declaration and 
Power of Attorney as originally filed with the U.S. Patent Office. To the extent that your address is incorrect, 
please cross it out and insert the correct home address as well as your country of citizenship. We request that we 
receive your signed Combined Declaration and Power of Attorney no later than November 28, 2001. This is the 
date by which the U.S. Patent Office has requested that we respond to the most recent communication. For your 
convenience, we enclose a self-addressed, stamped envelope. 

•While we are sending this communication to the most recent address of yours that we have on file, and 
the address at which we have spoken before, it is our understanding that you may have moved back to the Toledo 
area. A third party provided the second address above to us. As a result, we hereby send a copy of this letter and 
the attachments to the second address listed above as well. 
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which was filed onNovember 14, g^eX S&^d by most of the invent 
1863. Ftolly, reportable number is (248) 390-0633. 



Very truly yours, 
RADER, FISHMAN & GRAUER PLLC 




Michael B. Stewart 



MBS/amv 
Enc. 

cc Linda Lentz (w/enc.) 

Robert M. Leonardi, Esq. (w/enc.) 
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iter's Docket No. 65678-0037 PATENT 



COMBINED DECLARATION AND POWER OF ATTORNEY 

fORIGINAL, DESIGN, NATIONAL STAGE OF PCT, SUPPLEMENTAL, DIVISIONAL, 

CONTINUATION, OR C-I-P) 



As a below named inventor, I hereby declare that: 

TYPE OF DECLARATION 

This declaration is for an original application. 

INVENTORSHIP IDENTIFICATION 

My residence, post office address and citizenship are as stated below, next to my name. I believe that I am 
an original, first and joint inventor of the subject matter that is claimed, and for which a patent is sought on 
the invention entitled; 

TITLE OF INVENTION 
APPARATUS AND METHOD FOR TRACKING AND MANAGING PHYSICAL ASSETS 

SPECIFICATION IDENTIFICATION 

The specification was filed on November 16, 2000 and assigned Serial No. 09/714,702, 

ACKNOWLEDGMENT OF REVIEW OF PAPERS AND DUTY OF CANDOR 

I hereby state that I have reviewed and understand the contents of the above-identified 
specification, including the claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose information, which is material to patentability as defined in 37, 
Code of Federal Regulations, § 1.56. 
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POWER OF ATTORNEY 

I hereby appoint the following practitioner(s) to prosecute this application and transact all business 
in the Patent and Trademark Office connected therewith. 



Michael B. Stewart 
Robert M. Leonardi 
Phillip A. Rotman II 



Registration Number 36,018 
Registration Number 27,815 
Registration Number 38,290 



I hereby appoint the practitioners associated with the Customer Number provided below to 
prosecute this application and to transact all business in the Patent and Trademark Office connected 
therewith. 



SEND CORRESPONDENCE TO 


DIRECT TELEPHONE CALLS TO: 


Michael B.Stewart 


Michael B. Stewart 


Rader, Fishman & Grauer PLLC 


(248) 594-0600 


39533 Woodward Avenue, Suite 140 




Bloomfield Hills, MI 48304 




Customer Number: 010291 





DECLARATION 



I hereby declare that all statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true; and further mat these statements were 
made with the knowledge that willful false statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the United States Code, and that such willful false 
statements may jeopardize the validity of the application or any patent issued thereon. 



Andrew F. Suhy, Jr. 
Inventor's signature 




^TXJRE 



Date 



Z '■■ <T-<s>/ Country of Citizenship 



Residence 30 Avenue at Port Imperial #301, West New York, New Jersey 07093 
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COMBINED DECLARATION AND POWER OF ATTORNEY 

(ORIGINAL, DESIGN, NATIONAL STAGE OF PCT, SUPPLEMENTAL, DIVISIONAL, 

CONTINUATION, OR C-I-P) 



As a below named inventor, I hereby declare that: 

RECEIVED 

TYPE OF DECLARATION SEP 0 4 2002 

This declaration is for an original application. OFFICE OF PETITIONS 

INVENTORSHIP IDENTIFICATION 

My residence, post office address and citizenship are as stated below, next to my name. I believe that I 
am an original, first and joint inventor of the subject matter that is claimed, and for which a patent is 
sought on the invention entitled: 

TITLE OF INVENTION 
APPARATUS AND METHOD FOR TRACKING AND MANAGING PHYSICAL ASSETS 

SPECDJICATION DDENTDjICATION 

The specification was filed on November 16, 2000. I hereby authorize and request my attorney(s) of 
record in this application to insert the serial number and filing date of this application in the spaces 
that follow: Serial Number Q 9 / 7 1 4 7 OZ Filing Date: 1 1 / 1 6 /OQ 

ACKNOWLEDGMENT OF REVIEW OF PAPERS AND DUTY OF CANDOR 

I hereby state that I have reviewed and understand the contents of the above-identified 
specification, including the claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose information, which is material to patentability as defined in 
37, Code of Federal Regulations, § 1.56. 
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POWER OF ATTORNEY 

I hereby appoint the following practitioners) to prosecute this application and transact all 
business in the Patent and Trademark Office connected therewith. 



Michael B. Stewart 
Robert M. Leonardi 
Phillip A. Rotman II 



Registration Number 36,018 
Registration Number 27,815 
Registration Number 38,290 



I hereby appoint the practitioners associated with the Customer Number provided , below to 
prosecute this application and to transact all business in the Patent and Trademark Office connected 
therewith. 



SEND CORRESPONDENCE TO 

Michael B. Stewart 
Rader , Fishman & Grauer PLLC 
39533 Woodward Avenue, Suite 140 
Bloomfield Hills, MI 48304 

Customer Number: 010291 



DIRECT TELEPHONE CALLS TO: 

Michael B. Stewart 
(248) 594-0600 



DECLARATION 

I hereby declare that all statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true; and further that these statements were 
made with the knowledge that willful false statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the United States Code, and that such willful 
false statements may jeopardize the validity of the application or any patent issued thereon. 



SIGNATURES 




J. Aaron Bly 
Inventor's signature 

Date /V- g^-^oog Country of Citizenship {JSA 
Residence 2650 Pine Trace Drive #4, Maumee, Ohio 43537 
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David P. Francis 
Inventor's signature 

Date /2./>/)fl Country of Citizenship (J>S./I 

Residence 345 Wilderness Trail, Holland, Ohio 43528 : 



John M. Melby 
Inventor's signature 




Tiat* // A^/zooo Country of Citizenship 
Residence 2734 Sandalwood Drive, T oledo. Ohio 43614 



• ,1 

Patrick O'Brien Ubrf Cf. W 

Inventor's signature 7/ . . . — 

Date / !■/ As Country of Citizenship (j S A 

Residence 613 Midfield Drive, Maumee, Ohio 43537 



Brent Parent 
Inventor's signature 



Date Country of Citizenship 

Residence 247 Stone Oak Court, Holland, Ohio 43528 



Ryan J. Sherman 
Inventor's signature x^' 



Date t\-2A-oo Country of Citizenship UsA 
Residence 430 E. Fifth Street, Perrysburg, Ohio 43551 



Andrew F. Suhy, Jr. 
Inventor's signature 



Date Country of Citizenship 

Residence 1471 Indian Creek Drive, Perrysburg, O hio 43551 

RD098610.DOC 



(Declaration and Power of Attorney — page 3 of 3) 



65678-0037 (5397 DCCSP) 



PATENT 



APPARATUS AND METHOD FOR TRACKING 
AND MANAGING PHYSICAL ASSETS 

RELATED APPLICATIONS 

5 This application claims the benefit of U.S. Application Serial No. 09/441 ,289 filed 

November 16, 1999, U.S. Provisional Application Serial No. 60/166,042 filed November 17, 
1999, U.S. Application Serial No. 09/503,671 filed February 14, 2000, U.S. Application 
Serial No. 09/504,000 filed February 14, 2000, U.S. Application Serial No. 09/504,343 filed 
February 14, 2000, US Application Serial No. 09/653,735 filed September 1, 2000, and US 

10 Application Serial No. 09/702,363 filed October 3 1 , 2000, the contents of which are all 
hereby incorporated in their entirety by reference. 

B ACKGROUND OF THE INVENTION 
The present invention relates in general to systems for tracking and managing physical 
15 assets to promote the efficient maintenance of the assets while reducing cost. In particular, 
this invention relates to a computer based system for automatically gathering, analyzing, and 
delivering information relating to the maintenance of a plurality of such assets, such as a fleet 
of industrial equipment, so as to maximize productivity and to reduce the operating costs and 
administrative burdens associated with such assets. 
20 Many businesses operate a plurality of physical assets to assist in the performance of 

the daily activities that are required to produce goods or services. For example, a typical 
manufacturer of goods often uses a fleet of industrial equipment, such as forklifts, conveyors, 
machine tools, and the like, in its daily operations to facilitate the manufacture of goods for 
its customers. In a similar manner, a typical provider of services also often employs a 
25 plurality of assets, such as computers, communications equipment, photo imaging equipment, 
and the like, in its daily operations to facilitate the performance of services for its customers. 
Traditionally, businesses have purchased such assets for use in their facilities and have 
employed staff to operate and maintain the assets in furtherance of the manufacture of goods 
or the performance of services. 
30 Regardless of the specific nature of the business, the operation of these assets has 

usually been considered to be somewhat ancillary to the core nature of the business. In other 
words, although the use of these assets is helpful (indeed, sometimes necessary) for the 
business to manufacture the goods or provide the services in a cost efficient manner, the 
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ownership, operation, and maintenance of such assets is not, of itself, a core function of the 
business. Consequently, the costs associated with the procurement and utilization of such 
assets have not been traditionally monitored or analyzed by the business in great detail. 
Rather, such costs have usually been considered to be relatively fixed costs of doing business, 
and any management of such assets has been performed, if at all, by relatively low level 
employees having little training or inclination to increase productivity and reduce costs. 

Obviously, many businesses have been able to produce goods and provide services 
without actively managing the costs of obtaining and operating these assets. However, 
optimization of productivity and minimization of costs are key considerations in the modern 
business environment. Thus, it would be desirable to provide a computer based system for 
automatically gathering, analyzing, and delivering information relating to the procurement 
and utilization of a plurality of such assets, such as a fleet of industrial equipment, so as to 
maximize productivity and to reduce operating costs and administrative burdens associated 
with such assets. 

It would also be desirable to be able to provide different parties having an interest in 
the asset ready access to up-to-date real-time and historical access -to the information 
associated with asset usage, maintenance, performance, and the like. For example, besides 
the business using the asset, there is often a third party maintenance organization that helps to 
maintain the asset and a leasing company acting as the true asset owner that leases the asset to 
the business. Because the leasing company lacks appropriate information concerning the 
asset, the leasing arrangement typically takes this lack of information into account as part of 
the lease transaction, often through a combination of both a fixed lease amount tied to the 
asset regardless of use, as well as a financial cushion for the benefit of the true asset owner to 
cover unforeseen problems associated with the asset including over-use and improper 
maintenance. 

It would also be desirable to be able to provide different parties having an interest in 
the asset ready access to up-to-date real-time and historical access to the information 
associated with asset usage, maintenance, performance, and the like. For example, besides 
the business using the asset, there is often a third party maintenance organization that helps to 
maintain the asset and a leasing company acting as the true asset owner that leases the asset to 
the business. Because the leasing company lacks appropriate information concerning the 
asset, the leasing arrangement typically takes this lack of information into account as part of 
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the lease transaction, often through a combination of both a fixed lease amount tied to the . 
asset regardless of use, as well as a financial cushion for the benefit of the true asset o"Wner to 
cover unforeseen problems associated with the asset including over-use and improper 
maintenance. 

In some situations it is known to provide a fixed flat rate rental contract that has a 
variable overtime provision (e.g., an asset owner charges an asset user a flat rate plus an 
overtime charge in excess of a maximum usage level). However, a manual recordation of the 
additional time is required as opposed to automatic recording. 

In other situations it is known' to provide billing tied to calendar usage (e.g., monthly). 
However, such usage does not take into account objective usage criteria such as actual hours 
of operation during a fixed time period. 

However, if the leasing company and the business both had ready access to the same 
information concerning the asset, the leasing company may be willing to share an increased 
portion of the financial risk/reward associated with the asset's usage, maintenance, 
performance, and the like. With appropriate objective information it may be possible to 
distribute a portion of the responsibility to other responsible third parties including the asset 
manufacturer or supplier, and asset maintenance organization. 

It is known to record and store operational parameters or fault codes associated with 
the asset, which may be transmitted using a communications network to a central location for 
the purpose of undertaking diagnostics. It is also known to use handheld devices for the real- 
time sharing of information with a central system. The handheld device can access 
information from the central system such as the status of available inventory. The central 
system can also provide instructions to a user of the handheld device. Finally, it is known to 
use various electronic systems for monitoring inventory. 

However, if each of the entities involved with an asset had ready access to the same 
information concerning the asset, and the ability to update that information as well as related • 
information associated with maintenance of the asset on a real-time basis, the involved parties 
may be willing to share an increased portion of the financial risk/reward associated with the 
usage, maintenance, performance, or the like with respect to the asset. With appropriate 
objective information it may be possible to distribute a portion of the responsibility to other 
responsible third parties including the asset manufacturer or supplier, and asset maintenance 
organization. 
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SUMMARY OF THE INVENTION 
This invention relates to a computer based system for automatically gathering, 
analyzing, and delivering information relating to the procurement and utilization of a plurality 
of such assets, such as a fleet of industrial equipment, so as to maximize productivity and to 
reduce operating costs and administrative burdens. Each of the assets is preferably provided 
with a data acquisition device for sensing and storing one or more operating characteristics 
associated therewith such as a fault code generated by the asset when there is a maintenance 
problem or when routine, maintenance is required -in accordance with predetermined criteria. 
That information can be transmitted through space to a receiver connected to a local 
controller for storing such information and for transmitting such information over the Internet 
to a remote analysis system. The remote analysis system automatically updates individual 
records associated with each of the assets with the information received from the Internet. In 
response to such information, the remote analysis system automatically analyzes the newly 
provided information and generates reports regarding scheduled maintenance, warranty 
coverage, and other management information. These reports can be transmitted back over the 
Internet to an administrative controller for review by one or more persons responsible for 
managerial review. Additionally or alternatively, the remote analysis system can 
automatically post such reports on a website and, thus, be made available to one or more of 
such persons upon request. 

Not only can the information be provided to an administrative controller, but also it 
can be provided to third parties such as maintenance organizations, asset manufacturers or 
suppliers, and leasing companies. By providing up-to-date real-time and historical 
information concerning the asset, such third parties are willing to share the risk of the asset's 
usage, maintenance, and performance through creative arrangements with the asset user. A 
maintenance organization, for example, may be willing to enter into a fixed maintenance 
contract when it has the ability to readily detect adverse maintenance trends regarding an asset 
and is given the ability to take pro-active steps to address problems before they become 
major. The cost-savings associated with such a pro-active approach by an expert may be 
shared to the benefit of the business and the maintenance organization. Similarly, a leasing 
company that can reduce ownership risk through asset monitoring and appropriate asset 
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utilization is more likely to agree to a hybrid minimum term payment and asset usage billing 
system or even a usage based billing system with no minimum payments. 

Various objects and advantages of this invention will become apparent to those skilled 
in the art from the following detailed description of the preferred embodiment, when read in 
5 light of the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a schematic block diagram of a prior art computer based system for tracking 
and managing a plurality of assets. 
10 Fig. 2 is a flow chart of a prior art method for tracking and managing assets in 

accordance with the prior art computer based system illustrated in Fig. 1. 

Fig. 3 is a schematic block diagram of a computer-based system for tracking and 
managing a plurality of assets in accordance with this invention. 

Figs. 4A through 4C are three portions, respectively, of a flow chart of a method for 
15 tracking and managing assets in accordance with the computer based system illustrated in Fig. 
3. 

Fig. 5 illustrates the relationship of various parties to a database associated with an 
analysis controller. 

Fig. 6 is a flow chart of a subsystem illustrating the analysis of asset-related 
20 information to determine responsibility for asset utilization, and developing a lease 

relationship between an asset owner and an asset user based on asset utilization criteria. 

Fig. 7 is a flow chart illustrating the providing of maintenance to an asset in further 

detail. 

Fig. 8 is a flow chart illustrating what happens after a work order is generated based 
25 on maintenance approval. 

Fig. 9 is a flow chart illustrating authorization subsystem 200. 

Fig. 10 illustrates the operation of data acquisition and analysis subsystem 300. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
30 Referring now to the drawings, there is illustrated in Fig. 1 a schematic block diagram 

of a prior art computer based system, indicated generally at 10, for tracking and managing a 
plurality of assets, several of which are indicated generally at 11. The assets 11 are illustrated 
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as being a plurality of pieces of movable industrial equipment, such as a plurality, of - . . . . 
conventional forklifts or similar machinery, used in the manufacture of goods in a typical 
factory environment. However, the prior art method could be used to track and manage any 
type of asset 11, such as those described above, used in the manufacture of goods or the 
performance of services. The basic structure and operation of each of the forklifts 1 1 are well 
known in the art and, therefore, require no discussion for a complete understanding of this 
invention. 

The prior art system 10 further included a remote analysis system, indicated generally 
at 12, for tracking and managing the assets 1 1. The remote analysis system 12 was 
completely separate and apart from the assets 11 and included an analysis controller 13 
having one or more input devices 14 and one or more output devices 15 connected thereto. 
The remote analysis system 12 could be embodied as any conventional electronic controller, 
such as a microprocessor-based computer device. The input device 14 was embodied as a 
keyboard or other conventional mechanism for manually inputting data in electronic form to 
the analysis controller 13 for processing in the manner described below. The output device 
15 was embodied as a printer or other conventional mechanism for generating a hard copy of 
the management information generated by the analysis controller 13 in the manner described 
below. 

Referring now to Fig. 2, there is illustrated a flow chart, indicated generally at 20, of a 
prior ait method for tracking and managing the assets 1 1 in accordance with the prior art 
computer based system 10 illustrated in Fig. 1. Throughout this discussion, reference will be 
made to a first person or entity that owns or operates the assets 11 that are being tracked and 
to a second person or entity that is responsible for tracking the management information 
relating to such assets 11. Notwithstanding this, it will be appreciated that a single person or 
entity may not only own and operate the assets 11, but also track the management information 
relating thereto. 

In an initial step 21 of the prior art method 20, a record was created for each 
individual asset 1 1 by the person or entity responsible for tracking such assets, such as one of 
the forklifts 11 illustrated in Fig. 1. This record was created electronically within the analysis 
controller 13 by means of the input device 14 and included a variety of information that was 
desired to be tracked for management purposes. First, the record included information that 
uniquely identified the particular asset 11 being tracked. Such identification information 
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included, for example, data regarding the make, model, year, and serial number of the asset * 
11, plus any customer-assigned identification number. Second, the record included - 
information that related to the operational characteristics of the particular asset 11 being 
tracked, such as the physical requirements or limitations of the asset 11 (mast height, load 
5 capacity, type of tires for the forklift 11, for example), the type of fuel used, and the period of 
time or usage between the performance of periodic maintenance. Third, the record included 
information relating to the acquisition of the asset 11 by the owner or lessee thereof. Such 
acquisition information included, for example, the type and date of acquisition (purchase or 
lease, for example), the name of the owner or lessee, the location at which the asset 11 is 
10 used, the expected amount of usage of the asset 11 (one, two, or three shifts, for example), 
and the cost of the acquisition or lease. Furthermore, the record included an area for adding 
additional information or remarks as desired. 

In a second step 22 of the prior art method 20, it was determined whether a 
maintenance invoice had been received by the person or entity responsible for tracking the 
15 assets 11. Typically, a maintenance invoice was a written communication that was generated 
created by or at the request of the person or entity that owned or operated the assets 11. The 
maintenance invoice was usually generated upon the occurrence of an event relating to the 
particular asset 1 1 and generally contained information regarding the status of one or more 
operational characteristics of that asset 11. For example, after a particular forklift 11 had 
20 been operated by the person or entity that owned or operated the asset 1 1 for a particular 
period of time, it would require the performance of some maintenance. This maintenance 
may, for example, have constituted routine preventative service as a result of the elapse of a 
predetermined period of time or usage. Alternatively, such maintenance may have constituted 
non-routine service, such as a repair of a mechanical breakdown. In either event, a 
25 maintenance invoice was generated as a result of the performance of that maintenance. The 
occurrence of other events related to the assets 11 could also result in the generation of 
maintenance invoices. In many cases, the maintenance was performed by a maintenance 
organization having specialized knowledge of asset 1 1 and its long-term care. 

Regardless of the nature of the event that caused them to be generated, the 
30 maintenance invoices were generated in hard copy form and contained therein certain 

information that was desired to be tracked for management purposes, such as the date and 
nature of the maintenance that was performed, the amount of usage of the asset 1 1 as of the 
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date of such maintenance, and the cost of such maintenance. To perform the second step 22 : s .. 
of the prior art method 20, the maintenance invoices were required to be physically delivered 
from the location where the assets 11 were being used or serviced to the location of the 
analysis controller 13 or to the location of the input device 14 of the analysis controller 13. 
By physically delivered, it is meant that the maintenance invoice was transmitted in a non- • 
electronic, hard copy form (including, for example, by facsimile) from the person or entity 
that owned or operated the asset 11 (and who performed, or had performed, the maintenance 
on the asset 11) to the person or entity responsible for tracking the assets 11. 

As shown in Fig. 2, the prior art method 20 continuously repeated step 22 until it was 
determined that a maintenance invoice had been received by the person or entity responsible 
for tracking the assets 1 1. When that occurred, the prior art method branched from the step 
22 to a step 23, wherein the record contained in the analysis controller 13 relating to the 
particular asset 11 was updated with the information contained in the maintenance invoice. 
This step 23 was accomplished by utilizing the input device 14 to manually enter the 
information contained in the maintenance invoice into the record relating to the particular 
asset 11 contained in the analysis controller 13. 

Based upon the updated information contained in the record of the asset 11, the 
analysis controller 13 was programmed to perform a fourth step 24 of the prior art method 20, 
wherein it was determined whether a sufficient period of time or usage had elapsed as to 
trigger the performance of periodic routine maintenance for that asset 11. Typically, such 
determination was made by determining the amount of the elapsed time or usage of the asset 
1 1 (by comparing the most recent indication of the date or amount of usage of the asset 1 1 
with the previous date or amount of usage contained in the record stored in the analysis 
controller 13), and by comparing such elapsed time or amount of usage with a predetermined 
standard (also contained in the record of the asset 1 1 stored in the analysis controller .13). If it 
was determined that a sufficient amount of elapsed time or amount of usage had occurred, the 
method 20 branched from the step 24 to a step 25, wherein a hard copy maintenance report 
was generated by the output device 15. Then, in step 26 of the prior art method 20, the 
maintenance report generated in the step 25 was physically delivered from the person or entity 
responsible for tracking the asset 1 1 to the person or entity that owned or operated the asset 
1 1 . The maintenance report advised the person or entity that owned or operated the asset 1 1 
that the time had arrived for the performance of periodic routine maintenance. 
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; -- Thereafter, the prior art method 20 entered a step 27, wherein it. was determined .... 
whether a predetermined period of time had elapsed to generate a periodic management report 
covering some or all of the assets 1 1 being tracked. Alternatively, if in step 24 of the prior art 
method 20, it was determined that a sufficient amount of elapsed time or amount of usage had 
not yet occurred, the method 20 branched directly from the step 24 to the step 27. In either 
event, such management reports were typically generated on a monthly basis. Thus, if the end 
of the month had occurred, the prior art method 20 branched from the step 27 to a step 28 
wherein a hard copy management report was generated by the output device 15. Then, in step 
29 of the prior art method 20, the management report generated in the step 28 was physically 
delivered from the person or entity responsible for tracking the asset 11 to the person or entity 
that owned or operated the asset 1 1 The management report advised the person or entity that 
owned or operated the asset 11 of the status of some or all of the assets 11 that were being 
tracked, allowing various management oversight and decisions to be made at that time. 
Thereafter, the prior art method 20 returned from the step 29 to the step 22, wherein it was 
determined whether a maintenance invoice had been created by or at the request of the person 
or entity that owns or operates the assets 11 and was physically delivered to the person or 
entity responsible for tracking the assets 11. Alternatively, if in step 27 of the prior art 
method 20, it was determined that a predetermined period of time had not yet elapsed to 
generate a periodic management report covering some or all of the assets 1 1 being tracked, 
then the method 20 returned directly from the step 27 to the step 22. 

Referring now to Fig. 3, there is illustrated schematic block diagram of a computer 
based system, indicated generally at 30, for tracking and managing a plurality of assets, 
indicated generally at 31, in accordance with this invention. As with the prior art system 10 
described above, the illustrated assets 31 are represented as a plurality of pieces of movable 
industrial equipment, such as a plurality of conventional forklifts or similar machinery, used 
in the manufacture of goods in a factory environment. However, the method of this invention, 
can be used to track and manage any type of asset 31, such as those described above, used in 
the manufacture of goods or the performance of services. 

As above, the basic structure and operation of each of the forklifts 31 are well known 
in the art, and, therefore, require no discussion for a complete understanding of this invention. 
However, unlike the forklifts 11 of the prior art system 10, a data acquisition device 32 is 
provided on each of the forklifts 31 for sensing and storing one or more operating 
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" -characteristics of the associated forklift 31/ The basic structure and operation of each of the 
data acquisition devices 32 are conventional in the art. For example, each of the data - 
acquisition devices 31 may be embodied as an electronic processor or controller that can 
sense or be otherwise responsive to one or more operating conditions of the associated forklift 
31. Each of the data acquisition devices 31 can be responsive to any desired operating 
conditions of the forklift 31 that might be considered important in making effective 
management decisions regarding the operation of the forklift 3 1. Such desired operating 
conditions can, for example, include the time duration of use (and non-use), distances 
traveled, the extent of fork usage, the' nature of hydraulic system utilization, and the like. 
More typically for industrial assets, the most importanct criteria is time duration of use. The 
sensed operating conditions of the forklifts 3 1 are preferably stored at least temporarily in a 
memory of the data acquisition device 32 for subsequent communication to a remote analysis 
system, indicated generally at 50, for analysis in the manner described in detail below. Thus, 
the data acquisition devices 32 sense and store the desired operating conditions for each of the 
forklifts 31 during use. 

Each of the forklifts 3 1 is further provided with a transmitter 33 or other 
communications system for transmitting the acquired data from the data acquisition device 32 
to the remote analysis system 50 for analysis. Each of the transmitters 33 may be embodied 
as any conventional device for transmitting the acquired data to the remote analysis system 
) 50, such as a hard-wired communications interface. However, as is well known, each of the 
forklifts 31 is a movable vehicle that is capable of traveling extensively throughout the 
particular environment in which it is used. To facilitate the transmission of the acquired data, 
therefore, the transmitter 33 is preferably embodied as a wireless communications system, 
such as represented by an antenna 34. The transmitters 33 and the wireless communications 
.5 systems 34 can be embodied as conventional radio frequency transmitters provided on each of 
the forklifts 3 1 that transmit electromagnetic signals. However, other well known forms of • 
wireless communication, such as those utilizing light or sound, may be used in lieu of a radio 
frequency transmitter. 

The wireless communications systems 34 are adapted to transmit signals that are 
30 representative of the sensed operating conditions of the forklifts 3 1 through space to a 
receiver 35. In contrast to the forklifts 31 that can travel extensively throughout the 
environment in which they are operated, the receiver 35 is preferably provided at a fixed 
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location within that environment/ If desired, a plurality of such receivers 35 may be provided - 
at different locations within the environment in which the forklifts 31 are operated. As the 
forklifts 31 move about the environment during use, they will occasionally pass by or near the 
receiver 35. When this occurs, the receiver 35 receives the data transmitted from the 
5 respective data acquisition units 32. The receiver 35 is also conventional in the art. 

Preferably, the data acquisition units 32 and the receivers 35 are in bi-directional 
communication with one another. One advantage of such bi-directional communication is 
that the data acquisition unit 32 can send out a query signal on a predetermined basis to be 
received by the receiver 35 when the two units 32. and 35 are sufficiently close to 
10 communicate reliably with one another. Thus, when the data acquisition unit 32 contacts the 
receiver 35, the receiver 35 can send a first signal back to the data acquisition unit 32 to 
instruct it to begin transmitting the acquired data. At the completion of the data transfer, the 
receiver 35 can send a second signal back to the data acquisition unit 32 to acknowledge the 
receipt of the transmitted data. A conventional error checking algorithm can be used to 
15 confirm the accuracy and completeness of the transmitted data and, if necessary, request a re- 
transmission thereof. 

Another advantage of such bi-directional communication is that data in the form of 
new commands, program updates, instructions, and the like can be sent to the data acquisition 
units 32 from the receiver 35. In some instances, such as when a data acquisition unit 32 is in 
20 generally continuous communication with a receiver 35, a user of the forklift 31 can be 
prompted to provide certain information for transmission to the receiver 35 for further 
analysis. 

The receiver 35 is connected to a local controller 36. The local controller 36 is also, 
of itself, conventional in the art and may be embodied as an electronic controller that is 
25 adapted to receive and store at least temporarily the data from each of the receivers 35. 
Alternatively, if the assets 31 are fixed in position, such as in the case of a plurality of 
stationary machines used in a manufacturing environment, the receiver 35 or receivers 35 may 
be provided on movable structures that move about the environment to receive the 
information transmitted therefrom. In either event, it is desirable that the local controller 36 
30 acknowledge receipt of the information transmitted from the data acquisition devices 32, 
allowing the data acquisition devices 32 to delete the transmitted information and begin 
storing newly acquired information. A combined system including the data acquisition 
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device 32rthe transmitter-33; the wireless communications system 34, the receiver. 35, and 
software for operating the local controller 36 to gather and report data is commercially 
available, such as from ID. Systems, Inc. of Hackensack, New Jersey or Requip (formerly 
SXI). 

In a preferred embodiment, the various elements located in an asset 31 are hardwired 
into the electrical system of the asset to minimize the possibility of undesirable failure or 
tampering. 

Thus, after the forklifts 31 have been operated for a period of time, the local controller 
36 will have gathered and stored therein a certain amount of information regarding the 
individual operating characteristics for each of the forklifts 31. The local controller 36 is 
programmed to periodically transmit the information stored therein to the remote analysis 
system 50 for analysis. This can be accomplished by providing the local controller 36 with a 
conventional modem 37 or other communications device that can convert the stored 
information into a format that is compatible for transmission through an electronic 
communications network, such as the internet 40. As is well known, the Internet 40 is a 
digital electronic communications network that connects computer networks and 
organizational computer facilities around the world. Access to the Internet 40 can be easily 
obtained in most locations through the local telephone lines or by similar means. 

The system 30 of this invention may be used to track and manage a plurality of assets 
3 1 located at any desired physical location. Additionally, the system 30 of this invention may 
be used to track and manage assets 31 located at a plurality of different physical locations, as 
suggested by the dotted lines in Fig. 3. Each different physical location can be provided with 
one or more receiver 35, a local controller 36, and a modem 37 to connect the system 30 to 
the Internet 40. 

As mentioned above, the sensed operating conditions of the forklifts 31 are intended 
to be transmitted to the remote analysis system 50 for analysis. Referring again to Fig. 3, it 
can be seen that the remote analysis system 50 includes an analysis controller 51 that is 
connected to communicate through the internet 40 by means of a modem 52 or similar 
communications device. If desired, a communications server 51a may be connected between 
the analysis controller 51 and the modem 52. The communications server 51a is provided to 
selectively receive and organize the information from each of the local controllers 36 for 
delivery to the analysis controller 51. The analysis controller 51 can be embodied as any 
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conventional electronic controllerthat is capable of receiving the sensed operating conditions . 
of the forklifts 31 and for processing that information in a desired manner described in detail 
below. Ideally, the sensed operating conditions of the forklifts 31 are used to automatically 
generate and analyze management reports relating to the procurement and utilization of a 
plurality of the forklifts 31 to maximize productivity and to reduce operating costs and 
administrative burdens. An input device 53 and an output device 54, both of which are 
conventional in the art, may be connected to the analysis controller 51. 

As also shown in Fig. 3, one or more administrative controllers 55 (only one is 
illustrated) can be connected to the internet 40 through respective modems 56 or similar 
communications devices. Each of the administrative controllers 55 can also be embodied as 
any conventional electronic controller that can request and receive information from the 
remote analysis system 50 through the Internet 40. In a manner that is described in detail 
below, the administrative controllers 55 are provided to request and receive the management 
information generated by the remote analysis system 50. If desired, the local controller 36 
can also function as an administrative controller 55, although such is not necessary. An input 
device 57 and an output device 58, both of which are conventional in the art, may be 
connected to the administrative controller 55. 

Referring now to Figs. 4 A through 4C, there is illustrated a flow chart, indicated 
generally at 60, of a method for tracking and managing the assets 3 1 in accordance with this 
invention using the computer based system 30 illustrated in Fig. 3. Throughout this 
discussion also, reference will be made to a first person or entity that owns or operates the 
assets 31 that are being tracked and to a second person or entity that is responsible for 
tracking information relating to such assets 31. As above, it will be appreciated that a single 
person or entity may not only own and operate the assets 31, but also track the information 
relating thereto. 

In an initial step 61 of the method 60, a record is created for each individual asset 31 - 
by the person or entity responsible for tracking such assets, such as one of the forklifts 31 
illustrated in Fig. 3. The record can be created electronically within the analysis controller 51 
by means of the input device 53 and can include a variety of information that is desired to be 
tracked for management purposes, including all of the information described above in 
connection with the forklifts 11 and the analysis controller 13. Additionally, the record can 
further include information regarding the nature and time duration of a warranty provided by 
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the manufacturer or supplier of the assets 31.- Such -warranty information-can be used-in the; 
manner described in further detail below to automatically determine whether the 
responsibility for the maintenance being performed on the asset 31, either in whole or in part, 
should rest with the manufacturer or the supplier of the asset 31 or with the owner or user of 
the asset 31. 

In a second step 62 of the method 60, it is determined whether a maintenance invoice 
has been received by the person or entity responsible for tracking the assets 3 1 . Such 
maintenance invoices can be generated and delivered in the same manner as described above. 
If it is determined that a maintenance invoice has been received by the person or entity 
responsible for tracking the assets 31, the method branches from the step 62 to a step 63, 
wherein the record contained in the analysis controller 51 relating to the particular asset 31 is 
updated with the information contained in the maintenance invoice in the same manner as 
described above. Next, the method enters a step 64 wherein the record contained in the 
analysis controller 51 relating to the particular asset 31 is updated with information from the 
internet 40. Alternatively, if it is determined that a maintenance invoice has not been 
received by the person or entity responsible for tracking the assets 3 1, the method branches 
directly from the step 62 to the step 64. 

As discussed above, the local controller 36 will have gathered and stored therein a 
certain amount of information regarding the individual operating characteristics for each of 
the forklifts 31. The local controller 37 is programmed to periodically transmit the 
information stored therein to the remote analysis system 50 for analysis. The analysis 
controller 51 can include a memory circuit for storing this information from the local 
controller 36. The transmission of the information from the local controller 36 to the analysis 
controller 51 can be performed in real time, upon occurrence of predetermined events (such 
as the gathering of a predetermined amount of information), or at predetermined time 
intervals. In any event, the record contained in the analysis controller 51 is automatically 
updated with the latest information regarding the status of the asset 31, without any human 
intervention. 

Based upon the updated information contained in the record of the asset 31, the 
analysis controller 51 next determines whether a sufficient period of time or usage has 
elapsed as to trigger the performance of periodic routine maintenance for that asset 31. This 
determination can be made in the same manner as described above in connection with 24 of 
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- the prior art methdd-20. If it is^deterrnined-that a sufficient amount of elapsed time, or. amount 
of usage had occurred, the method 60 branches from the step 65 to a step 66, wherein an 
electronic maintenance report is generated. If desired, a hard copy of the maintenance report 
can also be generated by an output device 54 connected to the analysis controller 51. Then, in 
5 step 67 of the method 60, the electronic maintenance report generated in the step 66 is 

delivered from the person or entity responsible for tracking the asset 31 to the person or entity 
that owns or operates the asset 3 1 through the Internet 40. As above, the maintenance report 
can advise the person or entity that owns or operates the asset 31 that the time has arrived for 
the performance of periodic routine maintenance. .Moreover, if a specific fault code has been 
10 generated, that can be provided as well. Alternatively, the maintenance report 55 can be 

delivered to a specialized maintenance organization responsible for maintenance of the assets 
31. The electronic maintenance report can, for example, be delivered through the Internet 40 
to one or more of the administrative controllers 55 as desired. Alternatively, or additionally, 
the electronic maintenance report can be delivered through the Internet 40 to one or more of 
15 the local controllers 36. Also, in step 68 of the method 60, the electronic maintenance report 
generated in the step 66 is posted on a website maintained on the Internet 40. The website 
may be maintained either by the person or entity responsible for tracking the asset 31 or by 
the person or entity that owns or operates the asset 31 through the Internet 40. As opposed to 
the direct electronic delivery of the maintenance report to a particular person or group of 
20 persons contemplated in the step 67, the step 68 contemplates that the maintenance report is 
made available to such person or group of persons at their request over the Internet 40. 

Thereafter, the method 60 enters a step 69, wherein it is determined whether any 
maintenance that has been performed on the asset 3 1 occurred within the warranty period 
provided by the manufacturer or supplier. Alternatively, if in the step 65 of the method 60, it 
25 was determined that a sufficient amount of elapsed time or amount of usage had not yet 

occurred, the method 60 branches directly from the step 65 to the step 69. In either event,, this 
determination can be made by comparing the date of service or amount of usage of the asset 
31 with the warranty information contained in the record for that asset 31 contained in the 
analysis controller 51. If it is determined that service on the asset 31 occurred within the 
30 warranty period, the method 60 branches from the step 69 to a step 70, wherein an electronic 
warranty report is generated. If desired, a hard copy of the warranty report can also be 
generated by the output device 54 connected to the analysis controller 51. Then, in step 71 of 
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the method 60,' the electronic .warranty report generated in the step 70 is delivered from the-~ * 
person or entity responsible for tracking the asset 31 to the person or entity that owns or . 
operates the asset 31 through the Internet 40. As above, the warranty report can advise the 
person or entity that owns or operates the asset 31 that the service performed on the asset 31 
should be paid for by the manufacturer or supplier of the asset 31/ The electronic warranty 
report can, for example, be delivered through the Internet 40 to one or more of the 
administrative controllers 55 as desired. Alternatively, or additionally, the electronic 
warranty report can be delivered through the Internet 40 to one or more of the local 
controllers 36. Also, in step 72 of the method 60, .the electronic warranty report generated in 
the step 70 is posted on a website maintained on the Internet 40. The website may be 
maintained either by the person or entity responsible for tracking the asset 31 or by the person 
or entity that owns or operates the asset 31 through the Internet 40. As opposed to the direct 
electronic delivery of the warranty report to a particular person or group of persons 
contemplated in the step 71, the step 72 contemplates that the warranty report is made 
available to such person or group of persons at their request over the Internet 40. 

Thereafter, the method 60 enters a step 73, wherein it is determined whether a 
predetermined period of time has elapsed to generate a periodic management report covering 
some or all of the assets 31 being tracked. Alternatively, if in step 69 of the method 60, it was 
determined that a sufficient amount of elapsed time or amount of usage had not yet occurred, 
the method 60 branches directly from the step 69 to the step 73. In either event, such 
management reports are typically generated on a monthly basis. Thus, if the end of the month 
has occurred, the method 60 branches from the step 73 to a step 74, wherein an electronic 
management report is generated. If desired, a hard copy of the management report can also be 
generated by the output device 54 connected to the analysis controller 51. Then, in step 75 of 
the method 60, the electronic management report generated in the step 74 is delivered from 
the person or entity responsible for tracking the asset 31 to the person or entity that owns or 
operates the asset 31 through the Internet 40. As above, the management report can advise 
the person or entity that owns or operates the asset 31 of the same information as the 
management reports discussed above. The electronic management report can, for example, 
be delivered through the Internet 40 to one or more of the administrative controllers 55 as 
desired. Alternatively, or additionally, the electronic management report can be delivered 
through the Internet 40 to one or more of the local controllers 36. Also, in step 76 of the 
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-method 60, the electronic .warranty reportgenerated.in-the step;74 is posted on a website, 
maintained on the Internet 40. The website may be maintained either by the person or entity 
responsible for tracking the asset 31 or by the person or entity that owns or operates the asset 
3 1 through the Internet 40, As opposed to the direct electronic delivery of the management 
report to a particular person or group of persons contemplated in the step 75, the step 76 
contemplates that the management report is made available to such person or group of 
persons at their request over the Internet. 

Fig. 4C demonstrates an additional functional aspect of method 60 using the inventive 
system. In addition to determining whether a maintenance invoice has been received, if 
scheduled maintenance has been performed, and determining the party responsibility for 
certain maintenance activities, it is possible to poll asset data points at point 76 from an 
analysis controller database 78 associated with one or more discrete analysis controllers 51 
that may be associated with one or more businesses. A plurality of databases 78 is shown. 
One or more separate databases may be combined to form a logical database 78. When a 
maintenance organization has access to various asset fleets of the same type or make of 
equipment, it may be beneficial to analyze the relevant information using a larger available 
knowledgebase of information to analyze appropriate trends. By analyzing the data points, 
certain maintenance trends can be analyzed and problems can be anticipated before they 
affect asset utilization. For example, if it turns out that asset 31 has a tendency to need new 
batteries after a certain period of usage; the need for such batteries can be anticipated and 
stocked on site when appropriate to facilitate maintenance. As shown in Fig. 4C, once the 
various trends have been analyzed for assets 31, at decision point 80 it is determined whether 
preventative maintenance is required. If it is required, the maintenance is performed as 
shown at point 82 and the information is stored in database 78. The asset data points are then 
analyzed again until it is determined that no further preventative maintenance is required. 
Then the system terminates at point 84. Thus, figures 4A through 4C illustrate the use of 
critical information from assets 31 to perform maintenance and to provide a methodology for 
providing access to information by various third parties. 

There are a number of significant advantages to having appropriate access to and the 
ability to analyze data associated with an asset 31 and the interaction of various parties with 
that asset. Fig. 5 illustrates the beneficial interrelationships that promote efficiency by having 
the various parties associated in some way with an asset 31 in one or two-way communication 
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- with analysis controller 5 L either by way of administrative controller 55, reports 71 or 75,. " 
web site postings electronic mail, or the like. As illustrated, a maintenance organization 86, 
an asset manufacturer or supplier 88, asset user/business 90, and asset owner/leasing company 
92 all at least provide information to analysis controller database 78 of analysis controller 51. 
Both an individual user 85 and the asset 31 itself also provide data as illustrated in the figure 
and discussed herein. Therefore, at the very least each party is required to contribute pertinent 
information concerning its interaction with an asset 31 to database 78 of asset controller 51, 
where the information is available for further consideration and analysis. 

As already discussed above, asset 31 provides usage and performance data that is 
stored in asset controller 51 according to certain predetermined criteria important for that 
asset including such things as asset location, model, age, usage, and maintenance status. 
Once relevant data is collected, it is possible to analyze utilization of a specific asset 31. It is 
also possible to analyze a class of assets 31 using one or more types of available data. From 
such an analysis, best mode practices can be developed with respect to asset utilization 
including preventative maintenance and a determination of the extent of optimum asset use. 
More specifically, for. example, a business 90 may decide to standardize its fleet of assets, 
replace specific assets that have demonstrated unreliability, and either upsize or downsize a 
fleet to maximize safe asset utilization. 

As discussed in greater detail with respect to Fig. 9 below, utilization of asset 31 by an 
individual user 85 is also tracked. A review of the available data can also.provide detailed 
information on the interaction of a business 90 or individual users 85 with assets 31 as 
opposed to other businesses or users. From such an analysis it is possible to consider training 
issues, certification, and issues related to particular individuals, whose actions can have 
significantly influence asset utilization. 

The role of other vendors such as part distributors,, an example of another vendor 93, 
and maintenance organizations 86 can be compared with respect to other parties in similar 
roles or historical data to determine their effectiveness. While business 90 may provide its 
own maintenance of assets 31, a separate maintenance organization 86 is in the illustrated 
embodiment. 

A vendor may be penalized or rewarded depending on the results of its activities, 
providing increased incentives to promote efficiencies, With respect to asset manufacturers or 
suppliers 88, it is possible to compare assets provided by different parties 88 to determine 
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how well their assets perform jn..practice v Ttius, warranty issues, maintenance costs, lost 
operation time, and the like can be determined from an analysis of asset information over 
time or involving different manufacturers to provide guidance on how assets 31 from a 
particular manufacturer perform in different environments and as compared to competing 
assets of other manufacturers or suppliers in that environment. 

More specifically, for an asset manufacturer or supplier 88, warranty information as 
shown by steps 70 through 72 of Fig. 4B is of particular interest. While it may not be 
appropriate for a supplier 88 to be able to alter information in database 78, the ability to 
quickly and accurately collect information concerning warranty obligations and the like is of 
particular benefit to all of the parties. For example, warranty issues may be caught more 
quickly, ultimately reducing asset cost and operation while simultaneously promoting asset up 
time. 

The advantages of an asset owner 92 having at least one and possibly two-way access 
to the real-time and historical information stored in analysis controller database 78 as well as 

15 the ability to communicate with supplier 88, maintenance 86, and business 90, is illustrated in 
subsystem 98 illustrated in Fig. 6. It is assumed for the discussion that follows that the 
owner of the asset 31 is a separate asset owner 92 such as a leasing company, as opposed to 
business 90 itself, although this is not a requirement of the invention, subsystem 98 is often 
activated by the asset owner 92 using data from database 78, but typically utilizing its own 

20 lease administration and billing systems. In many cases it is also using its own fleet analysis 
and management systems, which are typically aggregating information from a number of 
different fleets associated with a plurality of businesses 90. These various systems, one or 
more of which may be used independently or in concert, are collectively shown at point 99. 
As noted above, web-site access, generated reports, analysis controllers 51, and 

25 administrative controllers 55 provide exemplary access points for pulling asset information 
from system 30. 

An asset owner 92 and an asset user such as business 90 share the common interest in 
maximizing efficiency by taking into account such variables as asset usage and asset costs. 
The more information that is available, the more likely that efficiency is maximized. In 
30 traditional leasing relationships involving non-fixed or movable assets such as forklifts where 
minimal asset utilization information is available, the burden of determining the point of 
maximum efficiency typically rests with business 90, since it has control over the asset. 



-19- 



65678-0037 (5397 DCCSP) 



PATENT 



Therefore, a leasing company 92 typically enters into a lease arrangement where a fixed lease- 
amount is paid in periodic payments by business 90 over the life of the lease. At best; only 
minor flexibilities are provided. When leasing company 92 regains control of an asset 31 at 
the end of the lease term, there is uncertainty concerning the condition of the asset. This 
uncertainty also typically rests with business 90 in the form of a financial cushion 
incorporated into the leasing relationship. 

However, such uncertainty is minimized in the present invention. As shown at point 
100, asset owner 92 is able to analyze the various desired objectively generated asset data 
points associated with an asset 31. As noted above, these data points can include the time of 
asset usage within a fixed time period, distance traveled, and certain performance parameters 
associated with the particular asset (e.g., hydraulic system usage or fork usage for fork lifts). 
As noted above, in practice, for industrial assets the time of use is the most important single 
data point. Then, as shown at point 102, asset owner 92 may analyze maintenance 
considerations. For example, a major routine overhaul as compared to a system failure can be 
analyzed. Then at point 104, the asset owner 92 can compare the raw data from the asset with 
maintenance conducted during the same time period. By comparing the raw data with 
maintenance considerations, the owner is able to analyze the asset utilization under the 
control of business 90 if maintenance organization 86 and supplier 88 are different third 
parties. For example, the asset owner 92 can determine that an asset 31 has been used very 
little during the time period, even allowing for maintenance. Alternatively, the owner may 
determine that the asset is being used continuously when not undergoing maintenance, 
possibly suggesting that additional assets may be appropriate to reduce overall maintenance 
stress on the pre-existing asset. 

Additional information can be analyzed by the asset owner as shown at decision point 
106. Typically, the information includes data associated with other parties having access to 
database 78. As shown at point 108, for example, the asset owner 92 can evaluate the 
maintenance relationship with maintenance organization 86. If the relationship has been very 
positive, an appropriate incentive may be provided to the organization in the form of shared 
cost savings. Alternatively, if the relationship has been negative, an appropriate penalty may 
also be implemented. The same considerations are available if business 90 acts as its own 
maintenance organization 86. 
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Similarly, the asset owner 92 may evaluate its relationship with the asset suppliers , 
as shown at point 110. The information may affect asset payments from the owner to the 
supplier or the future relationship of the parties. 

A further evaluation, shown at point 111, may include an analysis of individual users 
85 themselves associated with a specific business 90 and their interaction with particular 
assets 31 or classes of assets, and such things as training level, certification, accident rates, 
and the like as discussed with respect to Fig. 9 and authentication subsystem 200 below. 

One of the key advantages of the present invention is the ability to take data 
concerning any asset 31 and the interaction with that asset by any party, including user 85, 
maintenance organization 86, asset manufacturer or supplier 86, business 90, asset owner 92, 
or other parties/vendors 93. Moreover, groups of assets may be combined. Thus, it is 
possible to analyze data to identify the cost of owning or using any asset 3 1 and the 
productivity of that asset. Moreover, based on an adequately large statistical universe of data 
it is possible to benchmark asset utilization and cost against others in similar circumstances to 
identify best practices. Thus, it is possible to efficiency can be maximized while 
simultaneously minimizing unwanted waste by identifying time and cost saving opportunities. 
It is also possible to determine those parties providing best practice services with respect to 
asset utilization (e.g., maintenance) so that their services can be expanded and appropriate 
recognition given for their efforts. Alternatively, it is possible to identify parties providing 
unacceptable services so that appropriate remedial action may be taken (e.g., a user 85 has 
inadequate training to properly use an asset so additional training needs to be provided). 

In practice, the present invention provides a business 90 with a report screen showing 
information regarding the fleet associated with that business. Business 90 compares its 
current fleet information with its own historical information or pertinent information from 
unnamed companies in the same general industry. A side-by-side comparison will be 
provided, thereby providing a business 90 or the asset owner 92 with guidance on how to 
improve fleet utilization using the best practices comparison. 

These various advantages are applicable even if asset owner 92 arid business 90 are 
the same entity. However, more typically with industrial equipment, asset owner 92 is 
different than asset user 90, where the two parties have entered into a lessor/lessee 
relationship. In such a case, the information in database 78 may be used to mutually 
maximize the relationship between the asset owner 92 and the business 90. With appropriate 
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safeguards asset owner 92 may be willing to share in a greater portion of the risk associated 
with the utilization of asset 31 in determining a lease rate based on an analysis of each user 
fleet or individual asset as shown at point 112. Most significantly, rather than entering into a 
traditional fixed lease amount as noted above, asset owner 92 may be willing to enter into a 
hybrid lease arrangement wherein the lease charge may be a combination of one or more of 
the following elements: 1) a minimum payment that has to be made if asset utilization is 
below a pre-determined minimum threshold; 2) a usage based-payment that is made if usage 
is above the pre-determined minimum threshold and below a pre-determined maximum 
threshold; 3) a penalty payment or surcharge is made if utilization is higher than the pre- 
determined maximum threshold; and 4) payments/rewards based on incentive issues such as 
asset re-allocation or timely maintenance. 

The decision of whether to use usage-based billing based on one or more objective 
criteria based on an analysis of asset utilization is shown at decision point 114. The decisions 
to charge either a minimum payment if a certain usage level is not met, or to charge a usage 
penalty above a maximum appropriate usage level, are shown by decision points 116 and 118 
respectively. Thus, a variable-amount lease may be developed based on an analysis of 
objective criteria that is based in large part on the actual portion of an asset* s life that is 
consumed by the asset user (e.g., usage hours). In a preferred embodiment, the analysis is 
based on a pre-determined usage/pricing matrix in combination with actual usage for a 
specified time period. Once a level of maximum efficiency has developed, leasing will 
typically be primarily, if not solely, based on asset usage billing. 

Through the use of the innovative leasing arrangement based on improved information 
availability to asset owner 92, the expenses of an asset user such as business 90 can be more 
accurately aligned with usage and asset value consumption. More operational flexibility is 
provided to business 90. When leasing is based predominantly on asset usage billing, a 
business 90 is able to adopt true off-balance sheet financing (i.e., the business is not required ■ 
to note a financial obligation even in the footnotes of various financial reports as opposed to 
standard off-balance sheet leasing where a company must disclose the lease in footnotes even 
if the lease does not show up on the balance sheet). At the same time, asset owner 92, can 
collect information from a variety of sources to maximize its relationships with its own 
vendors and customers to the benefit of all related parties by minimizing inefficiencies and 
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providing appropriate accountability with maximum accuracy and validity tied to a minimal 
likelihood for mistakes, misinformation, or even fraud. 

These various factors can be adjusted dynamically by the asset owner 92 as a 
knowledge base is collected within its internal systems 99 and based on the actions of the 
other related parties. For a sophisticated asset owner with numerous fleets, it can conduct 
appropriate analyses over all of its fleets to determine certain trends, which it may 
advantageously use. 

For example, if supplier 88 or maintenance organization 86 is responsible for 
abnormally low asset utilization as opposed to actions within the control of business 90, then 
the risk associated with these possibilities can be shared between asset owner 92 and various 
affected businesses 90 and transferred in some fashion to the responsible party. Thus, in a 
more preferred embodiment of the invention, asset usage is adjusted for maintenance 
considerations if business 90 is not responsible for its own maintenance. 

As shown at point 120, once the readily available information is analyzed in view of 
the business relationship between an asset owner 92 and a business 90, an invoice and billing 
module associated with the asset owner's own internal systems 99 is invoked that generates 
an appropriate invoice that is sent by the asset owner to the business for payment and 
subsystem 98 terminates at point 122. In a preferred embodiment, once subsystem 98 is 
developed for a particular situation, and in the absence of an extraordinary event, invoicing is 
automated based strictly on the objective criteria developed with minimal outside 
involvement. 

A key advantage of the present invention is that real-time data is collected by data 
acquisition device 34 and timely transmitted to local controller 36 for transmission to 
database 78 of analysis controller 51. If incomplete or limited data representing only a small 
portion of the appropriate asset data points are transmitted, then appropriate decisions cannot 
be made to maximize asset utilization. For example, in the case of forklifts, both time of 
usage and distance traveled help provide information concerning asset utilization and 
maintenance considerations. 

Thus, the computer based system 30, including subsystem 98, of the present invention 
provides a superior method for tracking and managing the assets 31 than the prior art system 
10. First, by providing the assets with the data acquisition devices 32 and the 
communications system 33 and 34, the operational characteristics and other information 
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regarding the assets 31 is automatically sensed and transmitted to the. analysis controller 5 1 on 
a real time basis, without requiring human intervention or assistance. Second, the analysis 
controller 51 is programmed to analyze such information as it is received and to automatically 
generate maintenance and warranty reports in response thereto. Third, all of the reports 
5 generated by the analysis controller 51 are automatically delivered to the appropriate persons 
through the Internet 40, either directly to one or more of the administrative controllers 55 or 
by posting on a web site, electronic mail or similar mechanisms. Fourth, as shown by 
subsystem 98, the information can be used to maximize asset usage efficiency. As a result, 
the computer based system 30 facilitates the gathering, analyzing, and delivering of 
10 information relating to the procurement and utilization of the assets 31 so as to maximize 
productivity and to reduce operating costs and administrative burdens to the benefit of all 
parties having a relationship with the asset and an interest in its performance. 

The providing of maintenance to an asset 31 is illustrated in further detail in Fig. 7. In 
addition to determining whether it is necessary to provide scheduled maintenance as noted at 
15 step 65 of Fig. 4A, changes in operational parameters associated with asset 31 as shown at 
point 150 may result in the generation of a specific fault code if a maintenance problem is 
detected that requires a more expeditious response. The fault code may be generated by the 
asset itself using one or more sensors associated with operational parameters of asset 31 as 
shown by point 152 and communicated to the data acquisition device 32. In addition, 
20 analysis controller 5 1 may analyze the raw operational data received from the asset 3 1 and 
compare it with analysis controller database 78 including the history of the specific asset 31 
as well as the history of similar assets from which maintenance trends may be determined as 
discussed with respect to Fig. 4C above. Based on an analysis of such trends, proactive 
lower cost maintenance can be timely performed that results in the avoidance of higher cost 
maintenance at a later date, which happens in the absence of real-time information available 
for review and analysis. 

A fault code may even be generated based on the actions of the asset operator. In a 
preferred embodiment of the invention, an electronic checklist 154 is completed by the asset 
operator on a regular basis, which may include information concerning asset performance that 
is more detailed than that available from a review of raw operational parameters. In 
accordance with OSHA requirements, for example, at the end of each shift, a forklift operator 
must complete a checklist concerning the performance of the asset during the shift. Some of 
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the questions associated -with checklist 154 are directed to maintenance issues. Therefore, in 
a preferred embodiment of the invention, checklist 154 would be completed electronically at 
the asset 31, and transmitted by way of the data -acquisition device 32 to analysis controller 51 
as discussed above. The information would be analyzed to determine if an OSHA/repair need 
is identified. Preferably, the analysis is automated in accordance with a comparison of the 
operational status with pre-determined rules. For example, if a question asks if there is a 
hydraulic leak for a forklift and the answer is "yes", then maintenance would be appropriate. 

Once it is determined that maintenance of some type is required as shown at point 156 
based on an analysis of the operational status of asset 31, a maintenance report 66 is 
generated as also shown in Fig. 4A and made available electronically at point 67' such as by 
the Internet or by posting on a website as also shown in Fig. 4A. The use of electronic mail, 
or the providing of real-time access to the raw data stored within database 78 by the 
maintenance organization 86, shown in Fig. 5, is also possible to generate the maintenance 
report 66. An advantage of providing a maintenance organization 86 real-time access to the 
raw data representing the operational status of asset 31 is that it may develop specialized 
analysis tools based on its own expertise in maintenance, resulting for example in the creation 
of specialized rules for use in automatically analyzing raw data in determining whether 
maintenance is required, minimizing the need for manual review and determination. 

In a preferred embodiment, the priority of the proposed maintenance required 158 is 
noted on the maintenance report. For example, critical maintenance issues should take 
precedence over routine issues. Moreover, the system generally institutes an approval process 
as shown at point 160. For example, if the proposed maintenance is related to warranty work 
such as noted with respect to step 69 of Fig. 4B, the manufacturer or supplier should approve 
the maintenance. If a lessee is responsible for the proposed maintenance, it should approve 
the maintenance before it is performed. In some cases, the maintenance organization 86 itself 
approves the maintenance, such as when it has a contract that involves pre-payment of 
particular maintenance. Finally, as shown at point 162, in some cases it may be desirable to 
have the lessor or owner of the asset have the ability to review and override any refusals to 
perform maintenance since it has the ultimate responsibility for asset 31. If no approvals are 
given, the process is terminated at point 164. A review of any automated rules that generated 
a request for maintenance approval may also be appropriate. When maintenance approval is 
rejected, any automated rules that generated the original maintenance request can be fine- 



-25- 



65678-0037 (5397 DCCSP) 



PATENT 



tuned by including the results of the approval process. Over time, almost all 'maintenance 1 . 
requests should be generally approved. Information regarding approval is stored in database 
78. 

For preventative maintenance, it is expected that pre-approval will generally be 
granted by the necessary parties based on prior agreement as to the nature and timing .of such 
maintenance. 

Once maintenance has been approved, a work order 166 is generated. As shown in 
Fig. 8, work order 166 is sent electronically to appropriate maintenance personnel that 
contains all of the critical operating data required to effectively schedule and carry out the 
maintenance. Typically, for example, the data includes hour meter reading, any fault codes, 
asset identification criteria, operator of record, contact information, and asset location. 
Moreover, based on information contained within the fault code or retrieved from the 
knowledgebase, information concerning anticipated parts may also be provided as well as the 
nearest location from where they may be retrieved (e.g., at a customer location, or from a 
local servicing dealer). Finally, the work order 166 preferably contains the past recent history 
of the particular asset 31 so that the mechanic can use this information to expedite 
maintenance. 

In a preferred embodiment of the invention, the work order 166 is transmitted 
electronically to a handheld device 168 associated with specific maintenance personnel 
assigned to carry out the maintenance. Device 168 includes an appropriate graphical user 
interface (GUI) that permits the receiving and transmitting of both alphanumeric and 
graphical based information. Examples of hand held devices include a variety of systems 
produced that use either the Palm® operating system from Palm, Inc. or a sub-set of 
Microsoft® Windows® from Microsoft Inc. Moreover, in a more preferred embodiment of the 
invention, the hand held device 168 is in real-time two-way communication with analysis 
controller database 78. Thus, under appropriate circumstances the handheld device 168 can 
access such things as dealer billing systems, inventory listings, customer work order approval 
records, and fleet management information. Rather than having the work order include the 
past recent history of the asset 31 to be serviced, it is possible to use the two-way 
communication link to request the necessary history when advantageous to do so. 

Once the maintenance is completed, handheld device 168 is used to update database 
78 as shown at point 170, including labor information and an identification of any parts 
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required to effect a repair; . If not already: clear based on the contents, of database 78, the . 
inventor)' location from which any parts were pulled should also be provided. Ideally, "the 
information is transmitted on a real-time basis from the handheld device 168. Alternatively, 
however, the information can be transmitted upon routine synchronization of the handheld 
device with database 78. It is also possible to manually enter the information into the 
database 78. 

The maintenance information is passed to database 78 where it may be used to 
generate maintenance tracking reports 172, and comprehensive invoices 174 listing both labor 
and part costs. Since the information is integrated. with pre-existing asset information, no re- 
keying is required. Moreover, as noted above with respect to Fig. 4C, the complete 
maintenance history of a particular asset or class of assets may be reviewed and analyzed in 
detail for specific trends of interest. 

In addition, when parts are used, as shown at point 176, system 30 preferably permits 
comparison of the parts used with existing inventory for the specified parts storage location. 
Based on maintenance trends associated with a class of assets 31 or a specific asset 31, it is 
possible for the system to automatically order replacement parts for an inventory location if 
the number of parts in a particular inventory fall below a pre-determined threshold as shown 
at points 178 and 180. The threshold is calculated at least in part based on an analysis of the 
prior maintenance of both the asset 31 and the class of assets associated with the asset. Other 
factors may include the age of the class of assets, the time of the year, usage trends and the 
like. As one example, in the winter different parts may be required as opposed to in the 
summer. As another example, more tires may be required for a forklift asset if a number of 
the assets are reaching a preventative maintenance stage where tires have to be replaced. The 
system terminates at point 182. 

It is also possible to provide online copies of parts catalogs including part numbers 
and exploded views of parts, including to hand held device 168. In some cases a comparison 
table of equivalent parts may be provided to reduce part acquisition timing or cost. 
Moreover, system 30 preferably keeps track of part availability and cost throughout a parts 
availability network. Thus, no one party is required to keep as many items in stock since 
ready access to items stored at a different location is possible. Transaction costs in locating 
and requesting items from different locations is minimized since the information is readily 
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: stored and accessible from system 30. Item stock reduction at anyone location is also, v • v". 
possible for the reasons discussed above where careful quantity controls are implemented. 

Under some circumstances it may even make sense to have a central parts depository 
with inventory actually held and controlled by a third party such as a courier service. For 
example, the courier service can ship parts as needed to effect a repair or replenish a reduced 
inventory at a remote location. With a central depository, the cost of maintaining the 
inventory can be borne by the party having the best ability to do so. For example, if an asset 
owner 92 has many businesses 90 using a class of assets 31, it may be able to provide 
economies of scale to the businesses by being responsible for ordering and stocking inventory 
parts for use by all affected businesses. Non-related businesses may also be provided access 
to a part inventory at a higher cost, giving them a further incentive to actively participate in 
system 30 to enjoy improved economies of scale. Thus, system 30 provides enhanced 
customer service through reduced cost and a more efficient part access and ordering process. 

Inventive system 30 provides a number of additional advantages for maintenance. For 
example, through the use of electronic information transmission and analysis, maintenance 
information is transferred and available real-time for review and for the initiation of necessary 
actions such as approval, the tracking of performed maintenance, the ordering of replacement 
parts to replenish depleted inventories, and automatic invoice generation. Since asset 31 
communicates its own maintenance needs in consultation with an appropriate knowledgebase 
associated with database 78, human intervention is minimized. As more information is 
gathered over time, the scheduling of preventative maintenance can be optimized to eliminate 
either too little or too much maintenance. Further, system 30 automates a very paper- 
intensive and time cumbersome process by permitting direct communication with the various 
information elements associated with an asset 31. As a result, the flow of data is more 
effectively controlled, dispersed, routed, monitored, and acted upon. In practice, the number 
of people involved in the maintenance process can often be reduced while the speed of 
providing maintenance can be increased. Thus, potential downtime and related performance 
issues can be more timely addressed. 

A further aspect of the invention, authorization subsystem 200 within system 30, is 
illustrated in Fig. 9. Authentication to access an asset 31 is tied to pre-determined rules. 
Specifically, authorization subsystem 200 keeps track of all individual users 85 using an asset 
31. It prevents asset utilization by uncertified users 85. System 30 may require that a user 85 
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be trained or certified to utilize certain assets -31.. -Even if trained or certified,; system 30 may, : 
only allow a user 85 to access an asset 31 for a limited period of time within a pre-set time 
range (e.g., OSHA or other work regulations may only permit access for ten (10) hours within 
every twenty-four (24) hours). Further, authentication may be denied if a user 85 is found to 
have too many accidents. By tracking regulation requirements, training or certification issues 
and even accident rates, an asset 31 is more likely to be well maintained and well utilized. As 
a result, there are reduced operating costs, minimized potential fines through enhanced 
regulation compliance, and prolonged asset life through appropriate usage. 

Apart from user 85, maintenance considerations may make an asset 31 unavailable. If 
critical maintenance is required, the unavailability of an asset 31 may prevent unwanted 
problems resulting from inappropriate continued use, again reducing operating costs and 
extending asset life. 

In other situations, authorization subsystem 200 is essentially a beneficial subscription 
service. For example, a single asset 31may be available to different users at pre-set times 
based on a reservation system, which is tracked through authentication subsystem 200. A 
prior reservation may take precedence over a desire to use an asset without such a reservation. 
Alternatively, access to an asset 3 1 may be terminated if payments to a third party such as 
maintenance organization 86, asset supplier 88 or asset owner 92 are in arrears. Of particular 
benefit, even when authorizing access, the ability to track usage with respect to a particular 
user 85 permits different monetary or time-based asset access rates depending on the specific 
user or entity associated with that user. 

As shown at point 201, a record of user 85 is created that may be stored in analysis 
controller database 78. The information associated with user 85 preferably includes such data 
as a unique user code, user identification information (e.g., employer, location, address, and 
contact information) the number/class of assets for which the user is permitted access, safety 
record (e.g., number of accidents associated with each asset and over what period of total 
usage or time), and training or certification records. 

A user attempts to access a particular asset at point 202. The access may be through 
the use of an access device 204 associated with the particular user (e.g., access card, magnetic 
key, or key pad code) and a corresponding approval device 206 associated with an asset 31 
that is connected to data acquisition device 32 for authorization confirmation. In turn, as 
noted above, data acquisition device 32 is associated with transmitter 33, which is in selective 
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vcommunication with local controller 36. As shown at point. 208 , when a user attempts to 
access asset 31 for use, an attempt is first made to access remote system 50 for authorization. 
If communication is not possible, an attempt is next made to communicate with local 
controller 36 at decision point 210, which preferably includes a data cache for at least a sub- 
set of users 85 associated with a particular facility where an asset 31 is located. The data 
associated with local controller 36 may not be as up to date as that available from direct 
access to analysis controller database 78. In turn, if communication is not possible even with 
the local controller, an asset cache of data 212 associated with a particular asset 31 may 
optionally be available for access by approval device 206, as shown at decision point 214. 
Once again, the data may not be as up to date. On the other hand, at times, the data cached 
within asset cache 212 or local controller 36 may be more up to date than that associated with 
system 50. The appropriate data is communicated between asset cache 212 and local 
controller 36, and then between local controller 36 and system 50, as communication between 
the appropriate devices takes place. 

Once data related to asset 31 and user 85 is located, system 30 determines if user 85 is 
an authorized user for asset 3 1 at decision point 216, or if the asset 31 itself is available for 
user at decision point 218 in accordance with pre-determined rules or considerations such as 
those noted above. If authorization is not granted, a communication interface 220 associated 
with asset 31 preferably gives the reason for the denial and the steps required to obtain 
authorization 222. It may even be possible to use communication interface 220 to provide 
interactive training and certification under some circumstances. As suggested above, a 
communication interface 220 may even be used to complete an interactive asset checklist as 
discussed above before and after asset operation by each user 85. Finally, even if approval is 
given, confirmation as well as special instructions or information of importance to user 85, 
collected at point 224 (e.g., remaining access time, timing for re-training or re-certification, or 
next scheduled maintenance) may be displayed to the user. 

Finally, if a user 85 is not authorized, either because of communication problems or 
issues associated with either the user or the asset itself, preferably some type of supervisory 
override, such as a master access device or code and shown at decision point 226, may be 
selectively implemented between devices 204 and 206 to permit asset utilization. Even if 
there is such an override, however, information associated with asset utilization is still 
recorded and communicated as taught above. 
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- - -. . Finally, any pertinentauthentication subsystem datais stored in database 78/, . 
Moreover, pre-determined rules may be established that provide automatic instructions to 
system 30 when such authentication subsystem data should be communicated to a third party 
such as a supervisor, trainer, or security personnel as a result of a user attempting to access an 
asset 31 as shown at point 230. For example, if a user 85 needs to have additional training, 
that information needs to be communicated to the appropriate party (e.g., supervisor and 
trainer). Training may take place using internal personnel or it may be outsourced to a 
vendor 93 (shown in Fig. 5) in a manner similar to maintenance, as discussed above. System 
30 makes it possible to schedule training and evea track the cost and corresponding benefits 
of training through access to real-time and historical asset or user data not generally available 
except in accordance with the teachings of the present invention. As another example, if 
unauthorized personnel attempt to use an asset 31, it may be appropriate to send an urgent 
message to appropriate security personnel at the location of asset 31. Finally, authentication 
subsystem 200 terminates at end point 232. 

As shown most succinctly in Fig. 5, numerous parties have access to analysis 
controller database, which stores data with respect to asset 31 and various parties having a 
relationship to that asset. The collected data may be used or analyzed in any one of a number 
of different ways depending on the interests of the party. For example, a maintenance 
organization is interested in using the data available to improve maintenance and reduce 
associated costs; asset supplier 88 desires to examine and minimize warranty issues; and asset 
owner/leasing company 92 desires to appropriately maximize its return on investment, a 
desire shared with each business 90. From the perspective of an individual user 85, such 
issues as appropriate training and certification have also been discussed. 

"What if inquiries are particularly important to successful implementation of system 
30. For example, when proposing the use of system 30 to a party such as a potential 
customer, the ability to analyze historical data and performance with respect to similarly 
situated customers is invaluable to provide a breakdown of costs and possible cost savings. 
As noted above, with appropriate information, an asset owner 92, such as a leasing company, 
may be able to share in part of the risk of asset utilization with appropriate data access and 
control. 

To facilitate these types of analyses, it is important to have robust access to analysis 
controller database 78, which can actually be one or more databases of information tied 
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together so as to be accessible for the purpose of an analysis of -system 30. In a preferred - 
embodiment, hand held device 168 or a similar type of computing device provides a desirable 
access point to database 78. 

However, before the parties can take advantage of system 30, it is essential to create a 
■foundational base of information that provides a framework for further analysis. Ideally, pre- 
created forms or templates help facilitate data collection and analysis. For example, when 
talking to a potential customer, it would be helpful to have access to cross-reference materials 
related to competitor assets, lease pricing rate factors, historical data and the like. Certain 
query forms can be used to collect relevant raw data and other query forms can be used to 
retrieve useful data based on a consideration of the raw data to provide the basis for 
recommended courses of conduct to promote safe utilization and efficiency while reducing 
costs. Thus, the actual analysis typically takes place at a central location having the 
appropriate computational resources with the results preferably being transmitted to hand held 
device 168. Under some circumstances, an analysis is possible directly on-site using the data 
collected and analyzed without direct access to database 78 based on a sub-set of data and 
logic protocols in the form of analysis tools stored on hand held device 168. 

Even when not in real-time contact with database 78, hand held device 168 is often 
invaluable. It permits the automation of survey data entry by an account manager so that 
information concerning assets 31, a business 90, individual users 85, and other related parties 
may be entered on-site and later transferred to database 78. The use of paper forms and 
manual translation of information is eliminated, speeding up data entry. For example, in the 
past an account manager might have handled more than twenty (20) data sheets that tracked 
specifications of the current fleet of assets 31 for a new customer business 90. The data 
sheets were taken back to the office and manually entered into a local database. 
Simultaneously, an intermediate source of error related to manual keying or a similar 
translation method is eliminated. 

A data acquisition and analysis subsystem 300 is illustrated in Fig. 10. Subsystem 
300 facilitates the collection of raw fleet survey data 302 upon initiation of system 30 by a 
party so that a baseline level of data may be provided to system 30 for consideration and 
analysis. An account manager 304 collects raw data with respect to each affected asset 31 
and all parties having interaction with the asset such as the parties identified with respect to 
Fig. 5 above. Of course, other parties may also contribute fleet survey data if they have 
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interaction with an asset 31; The data is preferably inputted into a handheld device,168 using , 
pre-defined foims 306, transmitted to a desktop computer 308, and then ultimately stored in 
analysis controller database 78. To help with analysis of particular data, the process may be 
reversed, with data pulled from database 78 to desktop computer 308, transmitted to hand 
held device 168, and used by account manager 304 to perform a desired analysis for any 
affected party. 

Preferably, hand held device 168 uses an operating system 312 provided by Palm, Inc. 
A forms manager 314 from Puma Technologies, Inc. known as the Satellite Forms software 
development package is used to generate data forms 306, which are used to enter the required 
information or display stored data from hand held 168 or from analysis controller database 
78. When collecting raw data, account manager 304 follows inquiries associated with form 
306 to enter required information. In contrast to manual methods, it is preferably possible to 
advise when inappropriate data is entered or if a field is missed. Thus, any data entry errors 
can be addressed on the spot when the source of the original data is readily available. Hand 
held device 168 stores locally collected data 316 such as fleet survey data 302, may include 
retrieved data 318 from database 78, and a number of different analysis tools 320 for 
evaluating the stored data. For example, one analysis tool 320 may use a set of rules to 
estimate the total life of an asset under the circumstances currently in place at a business 90 
and compare them to known "best practices" for the same asset along with proposed process 
changes to increase asset life to reach the "best practices" level. 

Preferably, computer 308 includes an operating system 322 provided by Microsoft 
such as Windows® 98, Windows® Millenium or Windows® 2000. It has a plug-in 324 
provided by the party responsible for hand held operating system 312 to provide a 
synchronization conduit 326. Synchronization is handled through a conventional or USB 
serial data port on the desktop computer 308 and a cradle hardware device 328 associated 
with device 168. During use of synchronization conduit 326, data values and associated data 
stored on-hand held device 168 and desktop computer 308 are interchanged in accordance 
with parameters provided in forms manager 314 and a corresponding forms manager 
computer plug-in 330 on desktop computer 308. Desktop computer includes data from hand 
held device 168, data from database 78 to either be used locally by the computer or 
transferred to hand held device 168, data received from device 168 or manipulated locally 
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using one or more analysis tools 332 r .and data to be transmitted to database 7S for long-term - . : 
manipulation or storage. . ~ 

For example, when using subsystem 300 to transfer fleet survey data 302 that has been 
placed into hand held device 168 as locally collected data 316. The data transmitted includes 
both data elements and lists of value fields identifying a data source and the specific data 
values populating each data element. The data is then transferred to database 78 from 
desktop 308 in accordance with pre-detennined rules. Preferably, the data is associated with 
fixed fields that are consistently defined between hand held device 168 and database 78 so 
that the data merely populates the appropriate fields within database 78 after it is transferred 
from the hand held device. Alternatively, the data may be uploaded into a local analysis tool 
332 of desktop 308 such as a database or spreadsheet program for final manipulation and then 
storage in asset controller database 78. 

More particularly, in a preferred embodiment of the invention an account manager 
304 who is about ready to visit a business 90 determines the type of information that is 
relevant to be collected during the visit. Using the desktop computer, a list of values as well 
as data query forms are downloaded from asset controller database 78 and stored on the local 
desktop computer hard drive, and then transferred to hand held device 168. For example, 
when first taking an inventory of pre-existing assets for a new business 90, a list of valid 
value identifiers for forklift analysis may include the following data elements: 

1) Overall customer information 

2) Customer division information 

3) Locations of facilities within each division where forklifts are used 

4) Departments within each facility that use the forklifts 

5) Broad descriptions of the types of ways or industries for which the forklifts are used 

6) For each forklift: 

a) Manufacturer/Supplier 

b) Power supply type 

c) Mast type 

d) Tire type 

e) Forklift attachments 

f) Forklift type/model 

g) Forklift serial number 
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h) Any label used by a customer to uniquely identify the forklift 

i) Date the forklift went ^nto service 

j) Number of hours that the forklift has been in use according to its- meter, 
k) Lease/rental contract information 
- 1) Maintenance history 
m) Maintenance contracts, 
n) Forklift dealer 

o) The number of months/and/or usage hours covered pursuant to the 
manufacturer/supplier warranty, 
p) Original purchase cost 
q) Manufacturing date 

r) Forklift condition (e.g., based on a scale such as new or used) 
s) Application rating (e.g., heavy, medium or light) 

t) Administration fees charged for providing financing/maintenance or the like 
u) Criteria providing feedback concerning the number of hours at which 
preventative maintenance should be performed . 
v) Capacity, typically in pounds or kilograms 
w) Number of hours or shifts the forklift is used each day 
x) Number of days a week that a forklift is used 
The tables are downloaded to hand held device 168 using synchronization conduit 326 
and the relationship between forms manager 314 and forms manager computer plug-in 330. 
In practice, the transfer of data value tables and their related values has also included the use 
of a program written in a product called Sybase Powerbuilder from Sybase, Inc. Under such 
circumstances analysis controller database 78 is a Sybase database. Further, desktop 
computer 308 may include a different database manipulation program called DBASE acting 
as one of the local analysis tools to review and possibly manipulate data received from hand 
held device 168 or analysis controller database 78 before forwarding it to the receiving 
device. 

The collection of fleet survey data 302 is merely an example of subsystem 300 in use. 
Moreover, even when an account manager 304 is collecting fleet survey data 302, it is 
preferred that if some of the data associated with a survey is already stored in database 78 
(e.g., customer contact information, divisions, or asset locations), it is used to pre-populate 
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..appropriate forms 306;to;simplify, redundant data entry by the account manager. .Further, if an. 
error exists based on an inaccuracy in the pre-existing data, account manager 304 can eorrect . 
it - 

The collected and manipulated data provides a starting point for each asset 31 going 
forward as well as a base foundation for immediate asset fleet analysis since at least some 
historical data has preferably been collected for existing assets. Thus, even at the beginning 
of the utilization of system 300, the initially collected data can be analyzed in accordance 
with pre-existing data involving other fleets, best practices, and the like, to provide immediate 
guidance on how to improve current fleet utilization and efficiency. The same subsystem 
may be used to transfer data and recommendations back to hand held device 168, except that 
this time forms 306 perform a data presentation function as opposed to a query function. As 
suggested above, some analysis of data may be performed directly on hand-held device 168 
although more sophisticated analysis tools 332 are typically associated with desktop computer 
308 or asset controller 51 in view of their enhanced computational power and storage 
capabilities. 

Subsystem 300 has been shown using synchronization. It is recognized of course, that 
real-time access is also possible between hand held device and either asset controller 51 or 
desktop computer 308 without the need to use cradle 328. An advantage of real-time access 
between a hand-held device 168 and database 78 is that information may be immediately 
transmitted and received, providing access to the full range of data values and associated data 
available in database 78. The uploading and downloading of pre-created data forms 306 to 
help facilitate the collection and analysis of data is also expedited. Further, under some 
circumstances real-time error checking may be available. For example, if an account manager 
304 indicates the number of assets available at a physical location and the actual number in 
database 78 is different, the manager can be asked to undertake verification while still present 
at the physical location. Otherwise, to the extent that there are discrepancies, they may be 
considered after data synchronization takes place. 

The same methodology discussed with respect to subsystem 300 may also be used by 
maintenance personnel as discussed with respect to Fig. 8 above. Work order 166 acts as a 
pre-populated form 306 transmitted to a hand held device 168. Once the maintenance is 
completed a different form 306 may be used to communicate the necessary maintenance labor 
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and parts information so that a maintenance -tracking report 172, invoice 174, and . - 
determination of inventory replenishment 178 may be implemented. 

In accordance with the provisions of the patent statutes, the principles and modes of 
operation of this invention have been explained and illustrated in preferred embodiments. 
However, it must be understood that this invention may be practiced otherwise than as 
specifically explained and illustrated without departing from its spirit or scope. 
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. - ^ CLAIMS . - . 

What is claimed is: 

1. A system for gathering and analyzing data relating to a non-fixed movable 
asset comprising: 

a local controller located at a first location for acquiring data that is representative of 
at least one operating characteristic of the asset; 

an analysis controller located at a second location that is responsive to said acquired 
data from said local controller for generating an analysis of said acquired data; 

an electronic communications network connected between said local controller and 
said analysis controller and permitting transmission of said acquired data from said local 
controller to said analysis controller; and 

a hand held device receiving at least a sub-set of said acquired data stored in said 
analysis controller. 

2. A system as recited in claim 1, wherein said hand held device is in direct 
contact with said analysis controller. 

3. A system as recited in claim 1, wherein a second computer system is disposed 
between said analysis controller and said hand held device. 

4. A system as recited in claim 3, wherein said second computer system receives 
said acquired data, selectively modifies aspects of said acquired data, and forwards said 
acquired data including said modified aspects, to said hand held device. 

5. A system as recited in claim 1, wherein said hand held includes forms, said 
forms providing data values for the entry of foundational data associated with said data 
values, said data values and said foundational data being transmitted to said analysis 
controller. 

6. A system as recited in claim 5, wherein said foundational data is collected 
prior to said acquired data. 
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7. A system as recited in claim 1, wherein said hand held receives parts data 
associated with the asset, said parts data in the form of at least one of inventory, inventory 
location, and a parts catalog. 

8. A system as recited in claim 1, wherein said analysis controller includes a 
database, said database including data values, collected data and comparison data being 
available for a selected data value. 

9. A system as recited in claim 8, wherein said comparison data represents one of 
a best practice, level and past historical data to provide a base point for comparison with said 
collected data. 

10. A system as recited in claim 8, wherein said collected data includes at least 
user data representing a user accessing the asset. 

11. A system as recited in claim 10, wherein said user data includes at least a sub- 
set of user identification, and access authorization. 

12. A system as recited in claim 11, wherein said access authorization includes an 
analysis of user training or user certification with respect to a class of assets including the 
asset. 

13. A system as recited in claim 10, wherein said system includes an authorization 
subsystem, said authorization subsystem including an asset access mechanism to receive said 
user identification from a data transmission point associated with the asset and comparison of. 
said user identification from said data transmission point with said user identification from a 
remote database to confirm the identify of said user. 

14. A system as recited in claim 12, wherein said remote database is one of said 
local controller and said analysis controller. 
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15. A system as recited in claim J2, wherein said user identification is compared 
to access authorization to confirm proper authentication, said asset access mechanismr 
permitting operation of the asset upon proper authentication. 

16. A system for gathering and analyzing data relating to a non-fixed movable 
asset comprising: 

a local controller located at a first location for acquiring data that is representative of 
at least one operating characteristic of the asset; 

an analysis controller located at a second location that is responsive to said acquired 
data from said local controller for generating an analysis of said acquired data; 

an electronic communications network connected between said local controller and 
said analysis controller and permitting transmission of said acquired data from said local 
controller to said analysis controller, said analysis controller including a database, said 
database including data values, collected data and comparison data being available for a 
selected data value; and 

a hand held device including a form, said form providing at least a subset of said data 
values for the entry of foundational data, said foundational data being transmitted to said 
analysis controller and stored in said database. 

17. A system as recited in claim 16, wherein said comparison data represents one 
of a best practice level and past historical data to provide a base point for comparison with 
said collected data. 

18. A system for gathering and analyzing data relating to a non-fixed movable 
asset comprising: 

an asset access device; 

a local controller located at a first location for acquiring data received from said asset 
access device that is representative of a request for user authentication; 

an analysis controller located at a second location that is responsive to said user 
authentication to generate an analysis of said request; and 
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an electronic communications network connected between said local controller and 
said analysis controller and permitting transmission of said request from said local controller 
to said analysis controller. 

• 19. A system as recited in claim 18, further including an authorization 
subsystem, said asset access device receiving a user identification, said user identification 
being compared with a corresponding user identification stored in said asset controller, and 
providing selective access authorization based on additional user data stored in said asset 
controller for said user identification; 

20. A system as recited in claim 18, wherein said additional user data includes at 
least on of user training or user certification with respect to a class of assets including the 
asset. 
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- ABSTRACT OF THE DISCLOSURE 

A computer based system automatically gathers, analyzes, and delivers information 
relating to the procurement and utilization of a plurality of such assets, such as a fleet of 
industrial equipment, so as to maximize productivity and to reduce operating costs and 
administrative burdens. Each of the assets is preferably provided with a data acquisition 
device for sensing and storing one or more operating characteristics associated therewith. 
That infonnation can be transmitted through space to a receiver connected to a local 
controller for storing such information and for transmitting such information to a remote 
analysis system. The remote analysis system automatically updates individual records 
associated with each of the assets with the information received. In response to such 
information, the remote analysis system automatically analyzes the newly provided 
information and schedules maintenance as required. Information associated with the 
maintenance is also recorded electronically to maximize efficiency, provide historical trends, 
automate billing, and control inventory levels. The invention also includes an authentication 
subsystem and a mechanism for using a hand held device to collect and analyze data. 

R00985957 
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SYSTEM AND METHOD FOR DISPOSING OF ASSETS 

RELATED APPLICATIONS 
[0001] This application claims the benefit of U.S. Application 
Serial No. 09/441,289 filed November 16, 1999, U.S. 
Provisional Application Serial No. 60/166,042 filed November 
17, 1999, and U.S. Application Serial No. 09/503,671 filed 
February 14, 2000, and U.S. Application Serial No. 09/714,702 
filed November 16, 2000, all applications hereby incorporated 
by reference in their entirety. 

Background of the Invention 

1 . Technical Field , 

[0002] The present invention relates generally to an electronic 
system and method for use in the field of asset management and 
electronic commerce. 

2 . Description of the Related Art , 

[0003] The field of industrial equipment, such as forklifts, 
includes business entities at several different levels, 
including manufacturers, dealers, third-party financiers, and 
end-user customers. In one common arrangement, the dealer 
maintains an inventory of a wide variety of equipment types 
for rental to its end-user customers (i.e., the dealer's 
n rental fleet")- Some types of equipment in the dealer's 
rental fleet, however, are only infrequently needed by the 
dealer's end-user customers. Accordingly, such seldomly used 
items experience a reduced utilization rate compared to other 
items in the rental fleet. The dealer tolerates reduced 
utilization on the seldomly used items for a number of 
reasons, including maintaining customer satisfaction, and, 
hopefully, not giving the customer a reason to "shop around" 
for a new dealer who may have larger inventory of seldomly 
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used pieces of equipment. Conventional methods of conducting 
business, particularly providing rental fleets, have obvious 
shortcomings, inasmuch as the full economic value of some 
items in the dealer's rental fleet cannot be realized. 
[0004] Another common business arrangement involves a third- 
party financing company that buys pieces of industrial 
equipment from the manufacturer and then leases the equipment 
to the end-user customer. The customer then utilizes the 
industrial equipment (the customer's "fleet") in its business. 
In some circumstance, the customer actively "manages" the 
fleet of industrial equipment, attending to repair and 
maintenance, the acquisition of replacement equipment, and the 
retirement of old or unproductive equipment from the fleet. 
In other circumstances, however, the leasing company performs 
the asset management function. In either set of 
circumstances, challenges to be overcome by fleet managers 
include how to effectively and efficiently determine the 
timing, selection, and acquisition of replacement equipment, 
and the disposal of equipment being retired from the fleet or 
coming to an end of the lease term. 

[0005] Known approaches to deal with the foregoing challenges 
fall mostly into the use of manual methods. For example, 
determining whether to replace a poorly performing piece of 
equipment has typically been based on limited data relating to 
the equipment known by an experienced fleet manager. 
[0006] Another approach known for asset management pertains to 
passenger vehicle fleets and involves a computer-based, 
Internet-enabled vehicle selector program. The vehicle 
selector program provides average values for a plurality of 
0 different operating parameters and vehicle types that may be 
of interest to a fleet manager considering vehicle 
replacement. These parameters may include average monthly 
maintenance cost, and average miles per gallon. While the 
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vehicle selector program provides at least some useful 
financial and performance information to the fleet manager, 
such a system fails to address the ultimate question fleet 
managers .encounter : How does a change (i.e., an addition, or a 
subtraction) in the configuration of my fleet effect its 
overall performance? The known vehicle selector program 
simply does not provide information as to how a combined fleet 
would perform. 

[0007] Another challenge, particularly acute for third-party 
financing companies, involves how to effectively and 
efficiently dispose of assets whose lease has ended, or will 
•end in the near future. Conventional analysis approaches have 
been haphazard at best. They have included utilization of 
well-known auction systems, posting of off -lease equipment on 
electronic bulletin boards and the like for sale purposes, as 
well as utilization of consignment networks. One key • 
shortcoming of all these known systems of disposing of end-of- 
lease assets manifests itself in the failure to fully realize 
the full, remaining economic value of the asset. One factor 
contributing to this shortcoming involves the lack of 
information available to potential purchasers, renters and 
lessees. Information concerning the condition, treatment, 
and, particularly, the maintenance history of the asset during 
its operating life up to the time the asset is being offered 
for disposal are all important in determining a sales price, 
but are frequently unavailable. In any event, such 
information is never convenient to obtain. For example, it is 
known in the passenger vehicle fleet industry to make some 
level of maintenance history data on particular vehicle 
available to the potential- purchaser. However, to obtain this 
data, the potential purchaser must make a telephonic request 
to the asset's fleet manager, who manually looks up the 
information, and provides it (e.g., by way of facsimile) to 
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the potential purchaser if it is even available. Obtaining 
such information, therefore, involves a significant 
investment, both in time and effort. The investment is 
entirely lost if the purchase is not consummated, and is still 
partially lost even if the asset is finally transferred. The 
time lag involved in obtaining the information also leads to 
undesirable inefficiency. For example, a purchaser may have 
to make a quick decision regarding whether or not to buy a 
first asset, which would preclude a lengthy investigation of a 
second asset (e.g., the first asset may be sold by the time 
the investigation of the second asset has been completed) . 
This is particularly inefficient if the second asset is a 
better "fit" for the purchaser than the first asset. 
[0008] There is therefore a need for a system and method for 
facilitating transactions, and for managing assets of a fleet, 
that minimizes or eliminates one or more of the types problems 
exemplified above. 

Summary of the Invention 
[0009] In one aspect of the present invention, an electronic 
system is provided for facilitating transactions, particularly 
rental transactions. The electronic system provides, in- 
effect, a "virtual" rental fleet available to a user of the 
system, such as a dealer. The system includes an asset 
configuration unit, a market database, a market search module, 
and a communications interface. 

[0010] The configuration unit is responsive to input data 
•provided by a first user of the system for generating a 
profile of an asset. The asset profile comprises asset 
specification data and a bid definition. In a preferred 
embodiment the bid definition outlines parameters associated 
with a rental transaction of the asset. The market database 
is configured to store a plurality of asset profiles. The 
market search module is configured to search the market 
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database, based on search parameters specified by a second 
user, and generate an identification of assets. The bid 
module is configured to allow the second user to select one of 
the assets on which to bid. The bid module is also adapted to 
provide rental options to the second user, based on the bid 
definition for the asset. Finally, the communications 
interface is configured for facilitating the. electronic remote 
access by the second user of the system. 

[0011] Through the foregoing, a dealer or the like is provided 
access to a "virtual" rental fleet of assets, some of which 
are not owned or controlled by the dealer. The system allows 
a user, such as a dealer, to satisfy the requirements of the 
dealer's end-user customer without having to maintain 
infrequently used items in the dealer's own rental fleet 
(which experience low utilization rates and thus return on 
investment.) Additionally, the electronic system also allows a 
user, such as a dealer, who has its own under-utilized assets 
to consign such assets for rental by third parties, thereby 
allowing an increased, effective utilization rate. 
[00121 In another aspect of the present invention, an electronic 
system is provided for facilitating transactions, including, 
for example, assets disposal. The system, according to this 
aspect of the present invention, provides detailed information 
concerning an asset including the maintenance history data so 
that the user, a potential purchaser, rentee or lessee, may 
evaluate the asset. The system includes a first database, a 
market search module, and a communications interface. 
[0013] In a preferred embodiment, the first database is 
configured to store information associated with a plurality of 
0 assets, such as pieces of industrial equipment. The market 
search module is configured to search the first database, 
based on search parameters specified by the user in 
anticipation of at least one of a purchase, rental and lease 
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transaction. The market search module is also adapted to 
generate an identification of assets in accordance with the 
specified search parameters. At least one of the identified 
assets has a description that includes maintenance history 
data of the asset. The communications interface is configured 
to facilitate electronic remote access of the system by the 
user, which, in one embodiment, occurs over the Internet. 
[0014] The electronic system, according to this aspect of the 
present invention, maximizes value extraction by making 
detailed information concerning the asset readily available to 
the user. In particular, the maintenance history of the asset 
constitutes information that may increase the price obtained 
for the asset. For example, the maintenance history data is 
particularly important to a dealer class of users of the 
system who anticipate sub-renting or sub-leasing the asset for 
a short terra, inasmuch as a common commercial practice places 
the responsibility of maintenance on the dealer, not the end- 
user customer. Availability of information such as 
maintenance history data electronically, and immediately, 
substantially minimizes or eliminates the cost associated with 
information acquisition. 

[0015] In a refinement of the proposed asset disposition, a 
subsystem is disclosed, which compares a subset of all assets 
within the inventive system with a series of pre-defined 
conditions to determine if an action needs to be taken with 
respect to asset disposition. If a pre-defined condition is 
met, the system provides a ranked hierarchy of options based 
on the pre-defined condition that has been met. Associated 
with each option is the cost of invoking it, and the reasons 
30 why it is recommended for consideration. The hierarchy of 
options and the option determination assumptions are 
optionally reviewed and then presented to the asset user for 
cons iderat ion . 
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[0016] In another aspect of the present invention, an electronic 
system for modeling a simulated fleet is provided. The 
capability to model a simulated or "fantasy" fleet of assets 
provides the user with an effective and efficient mechanism to 
perform "what if" analyses. The user can then use the results 
to evaluate what effect proposed changes to an existing fleet 
would have on overall fleet performance. The electronic 
system for modeling a simulated fleet includes a simulated 
fleet configuration unit, a reporting and analysis module, and 
a communications interface. 

[0017] The simulated fleet configuration unit is provided for 
allowing a user to add a plurality of assets to the simulated 
fleet. Each asset is defined as having at least one parameter 
associated therewith. For example, in one embodiment, the 
parameter may be a total hourly cost to operate the asset . 
The reporting and analysis module is configured to generate a 
report having a composite output value that corresponds to the 
parameter, and, is characteristic of all of the assets in the 
simulated fleet. For example, the composite output value may 
be a composite total hourly cost for all the assets in the 
simulated fleet. Finally, the communications interface is 
configured to facilitate electronic remote access of the 
system by the user. For example, in a preferred embodiment, 
the communications interface allows access to the system over 
the Internet. This reduces the time and effort to obtain 
information. The system, according to this aspect of the • 
present invention, provides a more effective asset management 
tool than available using conventional systems. 
[0018] In a preferred embodiment, some of the assets contained 
in the simulated fleet correspond to assets already contained 
in the user's existing fleet. The remainder of the assets in 
the simulated fleet correspond 'to new or used assets proposed 
for acquisition by the user. The report generated by the 
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reporting and analysis module contains a composite output 
value representative of all the assets in a simulated fleet, 
namely, both the existing assets, and the proposed assets to 
be acquired. The report may be compared to a second report 
generated based on the performance of the assets in the 
existing fleet alone. Comparison of the two reports by the 
user allows accurate evaluation of the impact of the proposed 
changes . 

[0019] Other objects, features, and advantages of the present 
invention will become apparent to one skilled in the art from 
the following detailed description and accompanying drawings 
illustrating features of this invention by way of example, but 
not by way of limitation. 

Brief Description of the Drawings 
[0020] Figure 1 is a simplified diagrammatic and block diagram 
view of a fleet management and electronic commerce system in 
accordance with the present invention; 

[0021] Figure 2 is a simplified block diagram view illustrating 
functional modules according to the invention; 

[0022] Figure 3 is a simplified diagrammatic view of a screen 
output of the system of Figure 1, including a link to further 
fleet information; 

[0023] Figure 4 is a simplified diagrammatic view of a screen 
output of the system of Figure 1, showing detailed fleet 
information; 

3 

[0024] Figure 5 is a simplified flowchart diagram showing the 
steps for a method of adding an asset to a fleet; 
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[0025] Figure 6 is a simplified diagrammatic view of a screen 
output of the system of Figure 1, illustrating greater detail 
of a selected asset, including maintenance history data; 

5 

[0026] Figure 7 is a simplified flowchart diagram illustrating 
the steps for a method of consigning an asset for sale, rental 
or lease; 

10 [0027] Figure 8 is a simplified diagrammatic and block diagram 
view showing, in greater detail, the process for generating 
asset specification data and a bid definition; 

[0028] Figure 9 is a simplified diagrammatic view of a screen 
15 output of a fleet search module of the present invention; 

[0029] Figure 10 is a simplified diagrammatic view of a market 
search criteria input form; 

20 [0030] Figure 11 is a simplified "diagrammatic view of a screen 
output showing an " identification of assets resulting from the 
market search; 

[0031] Figure 12 is a simplified diagrammatic view of a screen 
25 output showing purchase, lease and rental options; 



[0032] Figure 13 is a simplified diagrammatic view of a screen 
output showing assets contained in a simulated or "fantasy" 
fleet; 
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[0033] Figure 14 is a simplified diagrammatic view of a screen 
output illustrating a report, including a composite financial 
parameter, for a simulated fleet; 

[0034] Figure 15 is a simplified flowchart diagram illustrating 
the steps for comparing assets with pre-defined conditions and 
then providing ranked options based on the condition met with 
respect to asset disposition; and 

[0035] Figure 16 is a simplified diagrammatic view of a screen 
output illustrating a report showing the status of asset 
disposition based on available options and their 
consideration . 



Detailed Description of the Preferred Embodiments 
[0036] Referring now to the drawings wherein like reference 
numerals are used to identify identical components in the 
various views, Figure 1 is a simplified diagrammatic and block 
diagram view showing an electronic system 2 0 for managing, 
tracking and conducting electronic commerce, with respect to a 
plurality of assets designated 221, 22n. The assets 221, 

22n are illustrated as being a plurality of pieces of 
movable industrial equipment, such as a plurality of 
conventional forklifts or similar machinery, used in the 
manufacture of goods in a typical factory environment. It 
should be understood, however, that system 20 is configured 
for operation with a wide variety of assets. System 20 is 
further configured to manage, and facilitate commercial 
transactions involving other assets (i.e., those not tracked) 
that are consigned or otherwise made available on an 
electronic market established by system 20. 
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[0037] Before proceeding to a detailed description of system 2 0 
keyed to the drawings, a general overview of the features of 
the present invention will be set forth. 

[0038] Electronic system 20 overcomes a problem identified in 
the Background, namely, the inability of prior systems to 
significantly facilitate business transactions that could 
increase utilization of infrequently rented assets in a user's 
rental fleet. Electronic system 20 includes functionality 
that allows users, in-effect, to consign assets on an 
electronic market in a manner that makes detailed information, 
such as maintenance history, readily available. Through the 
foregoing, users of system 20 having under-utilized equipment 
may use system 20 to "post" such equipment on the electronic 
market for rental, lease, or the like by other users of the 
system. Not only does system 2 0 enable some users to increase 
utilization of under-utilized assets, other users, (e.g., 
dealers) who have an occasional need for some equipment (e.g., 
to provide to their end-user customers) , can rent or lease 
equipment from the market in contemplation of sub-rental or 
sub-lease, without having to actually own the equipment. 
Detailed information, such as maintenance history data, allow 
users to make informed decisions. Equipment selection 
efficiency is significantly improved since it is commonplace 
for users such as dealers . to be responsible for the 
maintenance of equipment they sub-rent. Well -maintained and 
problem free equipment will likely be in the highest demand, 
and draw the highest lease and rental rates. 

[0039] Another shortcoming set forth in the Background involves 
the failure to realize an assets' full value upon disposal at 
0 the end of a lease term. Conventional systems are inefficient 
and inconvenient for making desired information available to 
new owners, lessees, and renters prior to their making 
decisions concerning such transactions. In accordance with 
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the present invention, electronic system 20.. is configured for 
facilitating transactions by creating an electronic market. 
In particular, system 20 is configured to allow remotely 
located users to electronically search the market based on 
search parameters they specify, and obtain a detailed 
description of the assets, including the maintenance history 
data. System 20 also includes a bidding mechanism configured 
to allow the user to bid on the assets. The contemplated 
transactions can be closed electronically. 
[0040] As stated in the Background, one shortcoming of 
conventional asset management systems involves the absence of 
an electronic "what if" analysis tool. The present invention 
overcomes this shortcoming, enabling the creation of a 
simulated ("fantasy") fleet. A user of system 20 may add a 
plurality of assets to the simulated fleet, including 
currently held or controlled assets in an existing fleet, such 
as assets 221, 22n, as well as new and/or used assets 
available in a "market" portion of system 20. The simulated 
fleet analysis tool allows the user to evaluate proposed 
changes to -an existing fleet. The tool may be used to compute 
parameters of interest that are characteristic of all the 
assets contained in the simulated fleet, which can then be 
compared to the same parameters for the user's existing fleet. 
[0041] Referring now to Figure 1, system 20 is configured for 
electronic remote access by a plurality of remote users, 
designated 231, 23n, through remote client computers 241, 
24n, over a global computer network, such as Internet 26. 
Private networks or dial-up connecting may also be used. 
Inasmuch as system 20 performs a variety of functions, such as 
0 tracking and management of assets, as well as facilitating 
electronic commerce, the users 231, 23n may fall into a 
plurality of user classes, which are accommodated within 
system 20 . 
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[0042] With continued reference- to Figure 1, remote client 
computers 241, 24n may be any one of a plurality of well., 
known computer systems, such as, for example, a personal 
computer (PC) running a Microsoft Windows operating system 
(e.g., Windows 95, Windows 98, Windows NT Workstation, and 
Windows 2000) , or a Macintosh computer (Apple Computer) . When 
used with Internet 26, remote client computers 241 24n are 

preferably configured to include a conventionally, 
commercially available web browser, such as, for example, 
Netscape Navigator 4 . 0 or higher, commercially available from 
Netscape Communications Corporation, or Microsoft Internet 
Explorer 4 . 0 or higher, commercially available from Microsoft 
Corporation, Redmond, Washington. The browser included on 
client computers 241, 24n preferably includes the 
capability of establishing a secure connection through 
Internet 26, by way of a firewall system 44 with web server 
30, for example, using a Secure Sockets Layer (SSL) protocol 
described below. Of course, other mechanisms for establishing 
a secure connection, such as the S-HTTP protocol may be used 
so long as both the client computers 24 and web server 3 0 are 
configured to include software compliant with the chosen 
protocol. Moreover, the present invention recognizes that 
different client software may be required when using private 
networks or a dial-up connection. 

[0043] System 2 0 interfaces with a tracking and management 
system 28, and preferably includes a first computer system, 
such as a web server 30, a second computer system, such as an 
application server 32, and a third computer system, such as a 
database server 34. One or more of the servers may be 
combined, depending on the size and complexity of system 20. 
Database server 34 is coupled to a market database 36 and a 
global asset database 3 8 comprising a fleet database 40 and a 
preconfigured asset database 42. In the client- server 
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architecture described herein, the "server" provides the 
information to the "clients" . Electronic system .20 may 
further include, in an alternative embodiment, a firewall 
system 44 . 

[0044] Tracking and management system 2 8 is configured to 
automatically gather, analyze, and deliver information 
relating to the procurement and utilization of assets 221, 
22n, so as to maximize productivity and to reduce operating 
cost and administrative burdens. Each asset may be provided 
with a data acquisition device for sensing and storing one or 
more operating characteristics associated with the asset. 
Such information can be transmitted to a receiver connected to 
a collection controller contained within system 28 for 
purposes of storing such information. System 28 may be 
further configured to automatically update individual records 
associated with each of the assets with information received, 
including for example, maintenance history information, and 
hour-meter readings. System 28 is operatively coupled to 
electronic system 20, particularly database server 34, as 
shown in Figure 1. This coupling allows system 20 to be 
updated with current information regarding the tracked assets 
221, 22n. Users 231, 23n may then access and review the 
status of their fleets, over Internet 26, using system 2 0 as a 
gateway. Tracking and management system 2 8 may be a system 
as described in co-pending application U.S. Serial No.: 
09/441,289, filed 11/16/99 entitled "APPARATUS AND METHOD FOR 
TRACKING AND MANAGING PHYSICAL ASSETS" , hereby incorporated by 
reference in its entirety. 

[0045] Web server 3 0 operates as a communications interface for 
I facilitating electronic remote access of system 20 by users 
231, 23n via client computers 241, 24n when using 
Internet 26. Web server 30 is preferably compatible with the 
ubiquitous HyperText Transfer Protocol (HTTP 1.1), and 
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includes the capability of establishing a secure connection 
with client computers 241, 24nvia, for example, the 
publicly available Secure Sockets Layer (SSL) protocol. 
Version 3 . 0 of the SSL protocol is commercially available from 
Netscape Communications Corporation. Web server 30 may 
comprise suitable hardware configured to handle anticipated 
traffic (e.g., requests, responses) therethrough, and may 
further execute conventional, commercial software, such as 
Windows NT 4.0 operating system software running Microsoft 
Internet Information Server (IIS 4.0) software, both 
commercially available from Microsoft, Redmond, Washington 
USA. 

[00461 Application server 32 is configured for running 
components of system 20, described functionally below, as well 
as serving reports. Application server 32 may comprise 
conventional, commercially available hardware, and include 
conventional, commercially available software such as Windows 
NT 4.0 operating system software, Microsoft Transaction Server 
2.0 transaction server software, as well as a conventional, 
commercially available reporting engine software, such as 
Power Builder or Crystal Reports . 

[0047] Database server 34 is configured for executing all 
database serving within electronic system 20, and may comprise 
suitably adapted hardware selected, in part, on anticipated 
traffic and data access response-time standards set for system 
20. Database server 34 may include conventional, commercially 
available software, such as Windows NT 4 . 0 operating system 
software, and Microsoft SQL server 7.0 database server 
software, both from Microsoft, Redmond, Washington USA. 
3 [0048] Web server 30, application server 32, and database server 
34 define a multi-tiered computing environment configured to 
achieve and implement the functionality to be described in 
greater detail hereinafter. It should be understood that 
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alternate architectures may be employed, achieving the. same, 
functionality, yet remain within the spirit and scope of the 
present invention. 

[0049] System 20 organizes asset information into several 
logical groups. Market database 36, shown diagrammatically in 
Figure 1, is configured for storing a plurality of asset 
profiles, associated with a corresponding plurality of assets, 
destined for disposal on an electronic market. Contemplated 
transaction types include sale, rental and lease. The asset 
profile includes two parts: asset specification data and a bid 
definition. The asset specification data includes a variety 
of details about the asset, as well as its maintenance 
history. The bid definition outlines the parameters 
associated with the above-described commercial transactions 
15 contemplated for the asset. Market database 36 is illustrated 
as a logically separate database, although it should be 
understood that market database 36, in alternative 
embodiments, may be implemented together on the same physical 
hardware as the global asset database 38. Market ' database 3 6 
is configured for rapid retrieval of asset information, as 
desired to facilitate the electronic commerce functionality of 
electronic system 20. 

[0050] Fleet database 4 0 is configured to store asset 
specification data for assets contained in fleets being 
managed by system 20. As used herein, "fleet" is a logical 
grouping or association of one or more assets, which may 
include assets 221 22n being tracked and managed by system 

28. A "fleet" may be either <i) a current fleet, or (ii) a 
simulated or "Fantasy" fleet. An existing fleet is a fleet 
containing assets under the control of a user, for example, 
through ownership or lease. A "Fantasy" fleet may contain (i) 
any assets in any of the user's existing fleets ("held 
assets"), (ii) new or used assets not held or controlled by 
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the user such as may be available for purchase, rental, or 
lease from third-parties via the market, or (iii) fictional, 
assets having a predetermined usage, and performance profile, 
from the preconf igured asset database 42. 

5 [0051] Preconf igured asset database 42 includes a plurality of 
asset specifications for various asset types. The asset 
specification includes values that may be a composite of a 
plurality of specific, actual assets of the same or similar 
type. For example, a model "A." forklift from a particular 

10 manufacturer may have an average monthly maintenance cost 

based on a long history of tracking the maintenance cost for 
model "A" forklifts. A preconf igured asset brings these 
composite values when added to a fleet. 

[0052] Firewall system 44 is disposed between the connecting 
15 network such as Internet 26, which is generally considered 

"insecure" , and the secure, private network on which servers 
30, 32, and 34 reside and execute. Firewall system 44 may be 
implemented in software, hardware, or a combination of both. 
As is known generally, firewall system 44 is configured to 
20 intercept messages destined for web server 30, or exiting 

therefrom, and to examine such messages, and block those that 
do not meet security criteria. Firewall system 44 enhances 
the security, and hence the integrity, of the electronic 
market established by the invention. Firewall system 44 may 
25 comprise conventional devices and methodologies known to 
those of ordinary skill in the art . 

[0053] Figure 2 is a block diagram view of the functional 
modules implemented on electronic system 20. Functional 
modules include a login or authentication module 46, a fleet 
30 module 48 comprising a simulated fleet module 50 and a current 
fleet module 52, a fleet search module 54, a market module 56 
comprising a market search module 58 and a bid module 60,- a 
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reporting and analysis module 62, and a bid definition module 
64 . 

[0054] Login 46 provides authentication functions, principally 
through a user ID/password approach. In one embodiment, 
electronic system 20 includes several classes of users: a 
guest class, a member class, and a dealer class. A guest is 
characterized as having no member privileges, but can view 
assets available in market database 36, as well as other 
public areas of electronic system 20. A member has an 
enhanced set of privileges. A member may create an actual 
fleet, and/or a simulated fleet, may conduct searches of the 
assets contained in the members existing and/or simulated 
fleets, may search market database 3 6 and bid on selected 
assets r run reports and conduct analyses, as well as place 
15 assets in market database 36 for disposal.. A dealer has 

access to the features available to members, but in addition, 
has access to a set of dealer tools generally unavailable to 
members, as discussed further below. Finally, electronic 
system 20 provides for an administrative class of users having 
heightened, administrative rights and privileges, for example 
to perform maintenance or reconfigure system 20. 
[0055] Before new users can practically use system 20, they must 
register. Accordingly, associated with login module 46 is a 
registration module (not shown) that allows a new user to 
register, typically as either a member, or a dealer. For 
registration activities and/or user profile changes, web 
server 3 0 and the corresponding client computer 24 communicate 
via a secure, encrypted connection, such as via the SSL 
encryption protocol. 
30 [0056] Regarding existing users, login module 46 is configured 
to automatically log the user in upon detection of an auto- 
login "cookie" . A "cookie" is a message that is given to a 
client (e.g., a web browser on a client computer 241, , 24n) 
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by a server (e.g.", web server 30) . Client computer 241 will 
cache the cookie, and store the cookie in a file on the client 
computer 241 if the cookie is a so-called "persistent" cookie. 
A part of the message is a description of the range of URLs 
(e.g., http://www.ironrhino.com) for which that cookie is 
valid, and a time period for which the cookie will persist. 
Any future HTTP requests by the client computer that fall 
within that URL, range (e.g., http://www.ironrhino.com) and 
valid time period will include, with the HTTP request, the 
current value of the cookie to the server. - In operation, 
electronic system 20 is configured to query a user 23 using a 
client computer 24 to determine whether the user wishes to 
save the user-login and password. If the user responds n YES" , 
then electronic system 20, particularly web server 30, sends a 
cookie to the corresponding client computer 24, wherein the 
cookie is stored in a file. When the user subsequently- 
accesses the URL from which the home page of system 2 0 are 
served, the browser portion of client computer 24 determines a 
match and will send the auto-login cookie, (containing 
login/password) to electronic system 2 0. .for authentication 
purposes. Upon successful login, login module 46 directs the 
user (e.g., member or dealer) to the user's start page (best 
shown in Figure 3) . 

[0057] With continued reference to Figure 2, fleet module 48 is 
configured to allow members and dealers to add their current 
fleet information into electronic system 2 0 for reporting, 
tracking and analyzing by module 62 . It should be understood 
that such activities provide much information regarding the 
status of the fleet, and upon which important business 
decisions can be based. Simulated fleet module 50 is 
configured to allow a user 23 to access, add, view, edit and 
delete assets in a simulated fleet. According to the 
invention, the "Fantasy fleet" feature allows accurate and 
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immediate "what if" analysis, unavailable through the use of 
conventional, systems. Current fleet module 52 allows a member 
or dealer to access, add, view, edit, or delete assets in one 
or more existing/actual fleets associated with the registered 
member or dealer. 

[0058] Figure 3 shows a user's "start" page 66 generated by 
fleet module 4 8 after a successful login. Start page 66 
includes a navigation pane, a search pane 70, a descriptive 
text pane 72, an advertising/promotions pane 74, an existing 
fleet information pane 76, and a simulated or "fantasy" fleet 
information pane 78. 

[0059] Navigation pane 68 includes, in the illustrated 
embodiment, a plurality of user-invoked (e.g., via "clicking" 
with a mouse or other pointing device) functions or operations 
that enable efficient navigation through the various modules 
of electronic system 20. Navigation pane 68 includes a Home 
button 80, a Search button 82, a "My Fleet" button 84, a 
"Fleet Builder" button 86, a STORE button 88, a Library button 
90, a Reporting button 92, and a FAQ (Frequently Asked 
Questions) button 94 . Wherever the user navigates to within 
system 20, navigation pane 68 will appear at the top of the 
screen. 

[0060] The "Home" button directs system 20 to take the user back 
to an initial login/registration page, which is then displayed 
on the user's client computer 24. Search button 82 invokes 
fleet search module 54, which is configured to search the 
user's fleets to identify assets based on user specified 
search criteria (e.g., make, model, and year of manufacture.). 
The "MY FLEET" button 84 invokes fleet module 48, taking the 
) user to the user's start page 66. The "FLEET BUILDER" button 
86 invokes a fleet builder wizard to lead the user through the 
steps of creating a new fleet of actual assets, or a simulated 
fleet. The "STORE" button 88 invokes market module 56, 
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providing the user with access to conduct searches of market 
database 36 to identify assets for purchase, rental or lease. 
Library button 90 invokes a library module (not shown) that 
allows the user to visit the on-line library of system 20 for 
access to downloadable documents. Reporting button 92 invokes 
reporting and analysis module 62 for obtaining reports 
containing analysis results for fleet assets or market items. 
FAQ button 94 invokes FAQ module (not shown) , allowing the 
user to access questions and answers of interest to the users 
of system 20 . 

[0061] Search pane 70 includes pull down menus for defining 
search parameters for conducting a search of either market 
database 36, or fleet database 40. The search is invoked, in 
an illustrated embodiment, by selecting (i.e., "clicking") on 
a "Search" button- 96 . 

[0062] The descriptive text pane 72 is configured to display 
predetermined text to the user, based on user interaction with 
electronic system 20. For example, descriptive text pane 72 
may include information instructing the user as to the 
organization of start page 66, and the available options, such 
as creating an actual fleet or a fantasy fleet. 
[0063] Advertising/promotions pane 74 is configured to display 
advertising or promotions that may be available. For example, 
certain pieces of equipment may be on a "lease special" , more 
details of which may be found in the site "STORE" (i.e., via 
"clicking" on "STORE" button 88 on the user's start page) . 
[0064] Current fleet information pane 7 6 comprise.s the interface 
through which a user interacts with electronic system 20 to 
create an actual or a current fleet, and to edit or delete a 
fleet. Fleet information pane 76 includes, in the illustrated 
embodiment, a "Create Fleet" button 98, an Edit button 100, a 
Delete button 102, a radio button 104, and a link 106. 
Selecting (i.e., "clicking") on the "Create Fleet" button 98 
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causes fleet module 48 to create a new fleet record in fleet 
database 40. In one embodiment, the record includes a. fleet, 
name, and a location. Edit button 100, when selected by the 
user, invokes current fleet module 52, which is configured to 
allow the user to edit the fleet name and/or location of the 
fleet selected by radio button 104. Note that in Figure 3, 
only one existing fleet (i.e., the "Denver Division") is 
illustrated; however, when two or more existing fleets are 
displayed, each have a corresponding radio button 104 
associated therewith, and only one of the radio buttons may be 
selected at a time (i.e., is darkened). The fleet having a 
darkened radio button is the "selected" fleet for purposes of 
Edit button 100, and Delete button 102. Selecting the delete 
button 102 causes current fleet module 52 to delete the 
selected fleet. from database 40. In the fleet information 
pane 76, in the illustrated embodiment, each existing fleet 
under the heading "Fleet Name" is configured to operate as a 
link to another page generated by system 20, particularly 
current fleet module 52. This "linked" page provides an 
identification of the-..assets contained in the fleet. The 
portion of the "linked" page that shows the asset 
identification is illustrated in Figure 4 (portions of the 
"page" have been omitted for clarity, like the Navigation pane 
68, which has was already been shown in Figure 3) . 
5 [0065] With continued reference to Figure 3, Fantasy Fleet 

information pane 7 8 includes a "Create Fantasy Fleet" button 
108, an Edit button 110, a Delete button 112, a radio button 
114, and a link 116. Pane 78, and buttons 108, 110, 112, 114, 
and link 116 operate in a substantially identical fashion to 
0 pane 76, buttons 98, 100, 102, 104, and link 106, as described 
above, except that they pertain to the Fantasy Fleets. 
[0066] Figure 4 shows a screen output current fleet module 52, 
responsive to a user's selection of link 106 in Figure 3. 
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Figure 4 includes an identification of the individual assets 
included in the "Denver. Division" fleet. In an illustrated 
embodiment, the identification includes a listing of the 
following parameters for each asset: a serial number , a make, 
a model, a capacity (pounds), an asset type, an application 
rating, a usage parameter, a utilization parameter (percent) , 
and a cost/hour (U.S. Dollars). 

[0067] The view illustrated in Figure 4 includes an "Add Asset" 
button 118, an "Add Fleet Charge" button 120, an Edit button 
122, a Delete button 124, a. plurality of radio buttons 126, a 
Move button 128, a pull down menu 130 including entries 1301, 
1302, 130n, and a link 132. The "Add Asset" button 118, 
when selected by the user, causes current fleet module 52 to 
add assets to the selected fleet. This process will be 
15 described in greater detail below. The "Add Fleet Charge" 
button 120, when selected, causes a charge (i.e., monetary 
charge) to be applied pro-rata to each of the assets included 
in the selected fleet. Edit button 122, and Delete button 
124, when selected by the user, respectively, cause current 
20 fleet module 52 to allow the user to edit, or delete an asset 
from the selected fleet. Which asset is affected is 
determined by which radio button 126 is selected. The edit 
function allows the user to edit the asset specification data 
associated with the asset. The "Move" button 128, when 
25 selected by the user, moves an asset (as selected by the radio 
button 126) , from the current fleet to the fleet chosen by the 
user from one of the entries 1301, 1302, 130n in pull down 

menu which are actual fleets as well as to thereby move real, 
existing assets between existing fleets. 
30 [0068] Figure 5 is a simplified flowchart diagram illustrating 
the steps for a method of adding an asset to a fleet. The 
method begins in step 134. The "Add Asset" function may be 
invoked from either simulated fleet module 50 or current fleet 
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module 52. The description of Figure 5 will be made with 
reference to module 52, although it should be understood that 
module 50 could be executing the steps as well. 
[0069] In step 13 6, current fleet module 52 obtains basic asset 
specification data responsive to input data provided by user 
23. While the particular types of information contained in 
the asset specification data will vary depending on the 
particular asset type involved, in the illustrated embodiment 
where the asset comprises an industrial piece of equipment, 
namely a forklift, the asset specification data is divided 
into four subgroups: "basic" , "additional", "usage" , and 
"performance". In one embodiment, the "basic" asset 
specification data may include an asset type (e.g., a standard 
forklift) , a make/model designation, a serial number, a year 
of manufacture, a capacity (e.g., in pounds) , and commentary 
text. In a constructed embodiment, "clicking" the "Add Asset" 
button causes a dialog box to be presented to the user having 
four tabs labeled "basic", "additional", "usage" and 
"performance" . The user moves from tab to tab, filling out 
respective forms, comprising input ..boxes and pull down menus. 
When complete, the user "clicks" on a "SAVE" link. The method 
then proceeds to step 138. 

[0070] In step 138, module 52 obtains "additional" asset 
specification data, which in the illustrated embodiment of a 
forklift may include a mast type (e.g., quad, standard, STD, 
TSU, etc.), a tire type (e.g., cushion, foam filled, non- 
marking, pneumatic, polyurethane, etc.), a "fuel type", a mast 
height, a tilt selection, an attachment description, an asset 
description, a condition, and an accounting system asset 
identification (ID) number, and a lease ID number. As will be 
described below, reporting and analysis module 62 generates 
reports that include financial parameters, on both a per-asset. 
and a per-fleet basis (e.g., average monthly cost) . Part of 
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the cost analysis derives from how much is paid monthly . to. ■ 
lease or rent the asset. This cost information, in one 
embodiment, is derived from information found in a separate 
accounting/leasing system (not shown) , and is identified and 
retrieved by electronic system 2 0 using the accounting system 
asset ID number, and lease ID number, provided as "additional " 
asset specification data in step 138. In an alternate 
embodiment, where the asset being added is not an asset 
covered under a lease in a leasing system in electronic 
communication with system 20, further financial -option 
information will be obtained from the user for the asset being 
added, which may include a purchase price (including 
applicable depreciation information so as to enable 
calculation of a monthly cost amount), a lease/rental amount, 
a lease-life rental-term, and a residual amount for 
lease/rent. The method then proceeds to step 140. 
[0071] In step 140, current fleet module 52 obtains "usage" 
asset specification data, which may comprise the following: an 
acquired-f rom name (i.e., name), an application rating (e.g., 
light, medium, heavy) , a date in service, an active asset 
designation (i.e., yes or no), a number of shifts used, an 
original cost per hour, an original usage, an original 
utilization, as well as other features. The method then 
proceeds to step 142 . 
25 [0072] In step 142, current fleet module 52 obtains 

"performance" asset specification data comprising an original 
hour meter reading, a number of warranty months, a number of 
warranty hours, a date warranted, a date warranty removed, an 
original equipment cost, a list price, a preventative 
maintenance (PM) hours specification, and a burden labor rate. 
It should be appreciated that the original hour meter reading 
provided to system 20 in step 142 has a date associated 
therewith. The meter reading and date form a data pair. 
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Future service events on the asset will generally also include 
further meter readings, such that the fleet database will have 
a plurality of date/meter-reading data pairs, each having a 
different date attached to it, for the life of the asset. 
[0073] When the user completes the entry of the asset 
specification data, the user will be prompted to enter 
maintenance history data for the asset being configured. As 
shown in decision block 144, current fleet module 52 
determines, through a suitable prompt to the user, whether 
further maintenance history data is available. If the answer 
is "YES", then the method branches to step 146. 
[0074] In step 14 6, current fleet module 52 obtains the next 
item of maintenance history data for the asset being 
configured. Maintenance history data may include the job 
date, a description of the problem (e.g., work-related, abuse, 
breakdown, regular maintenance) for which maintenance was 
required, a diagnosis, a commentary, a description of the 
actual work performed, the name of the vendor performing the 
work (if applicable) , whether the maintenance source is 
internal /external , whether covered under warranty, a 
description of the part replaced, a length of service, and an 
hour meter reading (usage) . Financial parameters for the 
maintenance items obtained from the user may include: Invoice 
Number, Invoice Date, Invoice Due Date, Invoice Paid Date, 
Total Cost, Labor Rate, Parts Tax, Labor Tax, Labor Hours, 
whether the item is Taxable, Exchange Rate, and Exchange Date. 
Financial parameter values for maintenance items may be used 
to determine total maintenance cost, and average maintenance 
cost for the asset. The method then loops back to decision 
element 144. If the answer to decision element 144 is U N0" , 
then the method branches to step 148. 

[0075] In step 148, the asset specification data, including 
maintenance history data, for the asset being configured is 
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stored' in fleet database 40. The method then proceeds to step . 
150, where the "add asset" portion of the current fleet module 
5 2 ends. 

[0076] The process 'for adding an asset to a "Fantasy Fleet", 
although not shown specifically, is the same as outlined above 
for adding an asset to a current fleet, except that fleet 
module 48 invokes simulated fleet module 50, rather than 
current fleet module 52. 

[0077] Figure 6 shows a screen output generated by current fleet 
module 52 for a configured asset. The configured asset 
comprises asset specification data 154 including maintenance 
history data 156.. In the example illustrated in the drawing, 
the user reaches the screen of Figure 6 by "clicking" on link 
132 in Figure 4. Through the foregoing, a user wishing basic 
information (i.e., a simple identification) of the assets in 
the user's fleet need proceed no further than Figure 4. 
However, for greater detail, including a description of the 
asset, the user can "drill down" by clicking on link 132 to 
reach Figure 6. Screen output 152 further illustrates an "Add 
Maintenance Item" button 158, an Edit button 160, a Delete 
button 162, a plurality of radio buttons 164 and links 166, 
and 167 . 

[0078] For assets being tracked and managed by way of system 28, 
maintenance history items, such as those illustrated as 
"Preventive Maintenance" and "Steering Mechanism", are 
automatically entered and available to electronic system 2 0 
through an information transfer, from a tracking system 28. 
For assets not tracked by system 28, such data is input to 
system 20 through "front-end" entry by the user (e.g., 
0 selecting the "Add Maintenance Item" button 158) . 

[0079] The Edit button 160, and the Delete button 162, when 
selected by the user, cause current fleet module 52 to allow 
the user to either edit, or delete, respectively, the 
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maintenance item selected .via one of the radio buttons 164. 
The foregoing availability of asset specification data, 
including maintenance history data, enhances real time 
management of assets in a fleet (e.g., provides the ability to 
identify high maintenance items) . 

[0080] The user, by selecting or "clicking" on link 166, is 
provided with even greater detail for a selected maintenance 
item, for example, the item captioned "Preventive 
Maintenance" . Selecting link 167 causes current fleet module 
52 to retrieve an image of the selected asset. Other ' features 
may be provided in the asset description shown in Figure 6, 
including links to asset specification information provided by 
the manufacturer, user manuals, repair manuals, and many other 
types of information that may be useful concerning the asset. 
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Virtual Rental Fleet - 

[0081] Referring now to Figure 7, in accordance with the present 
invention, electronic system 20 is configured to facilitate 
transactions where a first user, such as a dealer, can consign 
assets, such as forklifts, to the electronic market 
established by system 20 for sale, rental, or lease. This 
feature allows the first user, such as the dealer, to increase 
asset utilization by exposure of the asset to a broader 
audience than just the end-user customers of that dealer. 
Additionally, by making assets available that a second 
user/dealer can rent, with a view towards sub-renting to an 
end-user customer, electronic system 20 in-effect provides a 
"virtual" rental fleet. The rental fleet is "virtual" because 
electronic system 20 enables the second user/dealer to provide 
equipment to his end-user customer that he does not own. 
[0082] Significantly, the availability of maintenance history 
data for an asset allows the second user/dealer to make a 
better- informed decision before renting the asset. In the 
3 rent/sub-rent scenario this -is particularly important since 
the second user/dealer is typically responsible for the 
ongoing maintenance and service of the asset during the sub- 
rental term (i.e., the end-user customer typically does not 
pickup this responsibility during the sub-rental term) . 
5 [0083] Referring to Figure 7, a method of consigning an asset 
for sale, rental or lease on an electronic market includes 
several steps. These method steps will be described briefly 
as an initial matter, then in greater detail in- turn. 
[0084] Step 168 involves generating asset specification data 
30 including maintenance history data from input, data provided by 
a first user. 
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[0085] Step 17 0 involves generating a bid definition from 
further input data from the first user. 

[0086] Step 172 involves storing the asset specification data 
and the bid definition together in an asset profile in market 
database 36. 

[0087] Step 174 involves searching, market database 3 6 based on 
criteria specified by a second user and displaying the asset 
profile . 

[0088] Step 176 involves receiving a selection of an asset from 
the second user for placement of a bid. 

[0089] Step 17 8 involves providing, to the second user, one or 
more of a purchase, rental or lease options, in accordance 
with the bid definition. Step 178 also includes receiving a 
bid on the asset from the second user, based on the 
transaction - options . 

[0090] Step 18 0 involves receiving an acceptance of the bid from 
the first user. Once the bid has been accepted by the first 
user (i.e., the party "posting" the asset on the electronic 
market), bid module 60 operates to close -the transaction 
contemplated by the bid. 

[0091] Figure 8 provides greater detail of generating step 168 
(producing asset specification data) and generating step 170 
(producing bid definition) . In particular, Figure 8 
graphically shows in block form an asset profile 182 
comprising asset specification data 154, and a bid definition 
184. Referring to the upper half of Figure 8, asset 
specification data 154 includes a plurality of field values, 
including maintenance history data 156. Maintenance history 
data 156, in turn, comprises at least a date parameter 186, 
and an action 188 may be any of the information referred to 
above regarding the maintenance item. In the illustrated 
embodiment, generating the asset specification data may be 
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performed by executing the "add- asset" method described and 
illustrated in connection with Figure 5. 

[0092] Bid definition 184 defines the parameters associated with 
the asset being consigned for sale, rental or lease to the 
electronic market created by system 20. The bid definition 
184 defines the bounds of the sale, rental or lease 
transaction involving the asset. Bid definition module 64 
(best shown in Figure 2) is configured to generate the bid 
definition 184 as follows. In one embodiment, bid definition 
module 64, when invoked by the user, prompts the user for a 
bid date 190, an availability date 192, and information 
defining the classes of users allowed to bid on the asset 194. 
The bid date 190 establishes the date when the asset is 
available for other users to bid on. The availability date 
192 defines the date when the asset can be delivered. 
[0093] Classes of users 194 include a dealer class 196, and a 
member class 198. With respect to dealer class 196, a logical 
variable 200 is associated therewith, and may take either of 
the values U Y" , indicating that dealers are allowed to bid on 
the asset, or "N" , indicating that the dealers are not allowed 
to bid on the asset. As illustrated, logical variable 200 is 
a n Y" , indicating that dealers may bid on the asset. 
Likewise, with respect to member class 198, a logical variable 
2 02 is provided, and may also assume one of the values "Y" or 
«N" . In the illustrated embodiment, users who are in the 
member class may also bid on the asset. It should be 
understood that other logical arrangements, such as the use of 
a logical "0" or logical w l" could also be used, being an 
equivalent thereof. 
0 [0094] Bid definition 184 also includes, for each class of 

users, an identification of which of a sale, rental, or lease 
transaction is available to that class of user. As shown in 
Figure 8, all three of a buy option 204, a lease option 206, 



S5678-0042 (5672 DCCSP) 



and a rental . option 208 are enabled for both classes of users 
(e.g., members and dealers). This is shown by a logical 
variable 210, (which are all set to "Y" ) . For each 
transaction type available to a user class, respective 
transaction characteristic data is obtained from the first 
user. For example, the transaction characteristic data for a 
sales transaction includes a list sales price, such as shown 
in column 214, and a minimum sales price that a second user 
(e.g., another dealer) must submit to define a valid bid, such 
as shown in column 212. The transaction characteristic data 
for a rental transaction includes a list rental price for a 
predetermined period of time (e.g., a month), and a minimum 
rental price for that predetermined period of time that the 
second user must submit in order to define a valid bid. 
Finally, the transaction characteristic data for a lease 
transaction includes a total lease amount, and a term. 
[0095] In a constructed embodiment, the bid definition module 64 
executes a bid definition wizard. The information obtained 
from the first user to populate the fields described above is 
obtained through a step-by- step process, which leads the user 
along, allowing the' user to click on checkboxes to select the 
classes of users who will be allowed to bid, as well as what 
respective transactions will be available to that class of 
user. In addition, the bid definition wizard, as executed by 
bid definition module 64, allows direct entry of dates, and 
pricing, where appropriate. 

[0096] Bid definition module 64 is also configured for storing 
the asset specification data and the bid definition in an 
asset profile in a market database 3 6 when all the needed bid 
) definition information has been collected. This is shown in 
Figure 8 by a double arrowhead line to database 36. 
[0097] Having described what bid definition 184 is, and how bid 
' definition module 64 operates to obtain such information, a 
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description of the user's interaction with system. 20 will now 
be set forth.. To promote the greatest amount of flexibility 
for the user, electronic system 20 includes an asset 
configuration unit for preparing assets for posting and 
consignment. The asset configuration unit obtains the asset 
specification data and bid definition to form the asset 
profile, and comprises multiple interfaces/modules. These 
interfaces/modules include a create and define feature of 
market module 56, a sequence of the add-asset feature of fleet 
module 4 8 and the add-to-market feature of fleet search module 
54, and the add-to-market feature of fleet search module 54 
(for existing assets and shown in Figure 2) . These three 
approaches will be described in detail in- turn. 
[0098] First, in a create and define feature, the asset 
specification data (including maintenance history data) , as 
well as the bid definition are made by the first user directly 
out of market module 56. That is, when a first user, such as 
a dealer, wishes to post a piece of equipment on the 
electronic market, the first user, after logging in, initially 
selects the "STORE" button 88 (Figure 3) from the user'.s start 
page 66, which invokes market module 56. Market module 56, as 
one of its available functions, would directly allow 
configuration of an asset (i.e., input of asset specification 
data including maintenance history data, as well as the bid 
definition) . When completed, the asset is stored in the 
market database. 

[0099] Second, if the user wishes to post an asset on the 
electronic market, but the asset does not presently 
"electrically" exist in one of the user's fleets, then the 
) user can follow the u add asset" process described above in 
connection with Figure 5. Once the asset is created 
"electrically" , the user then "clicks" the "Add to Market" 
button. 
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[00100] Third, existing assets may be configured for posting 

as follows. A user, for example a dealer, who wishes to post 
the existing asset in market database 36, would invoke the 
fleet search module 54 by selecting the Search button 82. 
found on start page 66 (Figure 3) . Figure 9 illustrates a 
search form that allows the user to search the user's fleets 
to identify assets based on specified search criteria. An 
identification of assets satisfying the criteria is returned 
by fleet search module 54. The user then selects the asset to 
be placed on the market. As shown in Figure 9, this selection 
is done by selecting one of the radio buttons adjacent the 
desired asset, and then "clicking" the "Add to Market" button 
215. Since the asset specification data for the selected 
asset is already stored in the fleet database 40, only bid 
definition 184 need be generated for the asset to prepare it 
for posting. "Clicking" on the "Add to Market" button 215 
invokes the bid definition wizard, described above in 
connection with Figure 8. 

[00101] Through the foregoing functionality, electronic 

system 20 allows a user,- such as a dealer, to consign an asset 
to an electronic market for rental, lease, and/or sale by a 
second user, such as another dealer. This functionality 
enables the first dealer to increase utilization of 
infrequently used pieces of equipment by making those pieces 
of equipment available to a larger audience of dealers and 
end-user customers. In addition, the second dealer realizes 
an increased virtual inventory of equipment from which to, 
preferably, rent (with a view towards sub-renting to an end- 
user customer) . 

[00102] In an alternative use of system 20, a non-dealer 

user of system 20, for example, an equipment leasing company, 
may purchase infrequently used equipment, for example, and 
make such equipment available through market database 36. The 
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universe of dealers '(with the dealers sub-renting the 
equipment to end-user customers) and end-users may have a - 
sufficiently high aggregate need for such piece of equipment 
to justify the purchase and ongoing rental to third parties. 
In this embodiment, the end-user customer need not be aware of 
the actual ownership of the equipment, and will look to the 
dealer for service, maintenance and the like. 

End-of-Lease Disposal 
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[00103] A particular business type of user who may take 

particular advantage of electronic system 2 0 is one engaged in 
the business of financing the capital requirements of other 
companies. For example, such financing may involve the lease 
or rental of forklifts 22i, .., 22n to the company who 
actually uses the forklifts in its business, and who pays a 
lease or rental fee. This type of user often has a large 
number of leases that may represent literally thousands of 
individual assets that are or will periodically be coming off 
of lease. Since this type of user has no direct use for such 
assets, such assets must be disposed of in an effective 
manner. The assignee of the present invention has determined • 
that the information acquired during the tracking and 
management of the asset while the asset was being leased can 
25 be leveraged into a value proposition when such asset comes 
off of lease and must be disposed of. In particular, the 
assignee of the present invention has determined that keeping 
maintenance history data associated with assets on lease 
becomes a value-added feature when disposing of the asset in a 
30 fashion to be described in detail now. 

[00104] Figure 10 shows a market -search parameter input form 

216 generated by market search module 58 configured to allow a 
search of market database 36. Assets that have been tracked 
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and managed by tracking and management system 2 8 over an 
operating life (or portion thereof) have associated therewith . 
a substantial amount of valuable information, including 
maintenance history data. When such assets come off of lease, 
the particular type of user described above (i.e., lessor) 
transfers these assets into market database 36. Each asset in 
market database 36 has an associated asset profile comprising 
both asset specification data (including maintenance history 
data) and a bid definition. Accordingly, since these end-of- 
lease assets already have the asset specification data 
defined, only a bid definition needs to be created. 
Completing the bid definition may be done manually for each 
asset, or may be automated through the use of a knowledgebase 
developed over time. Once the asset profiles for the end-of- 
lease assets are stored in market database 36, then the other 
users of electronic system 20 will be able to electronically 
search the market database, based on search parameters they 
specify, in anticipation of a purchase, rental or lease 
transaction. 

[00105] Referring to Figure 10, once such a user invokes 

market search module 58, search parameter input form 216 is 
displayed. Included in display 216 is a series of radio 
buttons: a lease radio button 218, a buy radio button 220, a 
rent radio button 222, and an "All" radio button 224. As 
illustrated, the lease radio button 218 has been selected; 
accordingly, all assets in market database 3 6 that are 
available for lease, and satisfy the other search parameters, 
will be identified and returned in an output display, shown in 
Figure 11. It should be understood that the search results 
0 may be further limited based on the other search parameters 
like the class of user conducting the market search (e.g., 
whether the user is a "member" or "dealer", and whether a 
particular asset has been configured to be bid on by a 
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"member" or "dealer"). Selecting the "All" radio button 224 
results in a search that identifies all assets (i.e., not 
limited to any one transaction type) . Figure 10 also shows 
that a market search may be limited by a lower list price 226, 
5 an upper list price 228, as well as a plurality of further 

parameters, such as asset type, make/model, condition, year of 
manufacture, and availability date, as also illustrated. Once 
the user has defined the search, the market search is invoked 
by "clicking" the Search button. 230. 
10 [00106] Figure 11 shows a screen output 232 of market search 

module 58. Output 232 includes an identification 234 of the 
assets satisfying the search parameters. m the illustrated 
embodiment, identification 234 includes a date available 
parameter, an asset description parameter, a make and model 
15 parameter, a capacity parameter, a year of manufacture 

parameter, a usage rating parameter, and a status parameter. 
The status data in the status parameter column, if any, is 
indicative of whether or not the asset has been sold. As 
shown in Figure 11, status data 235 for the "Allegany Mega-8" 
20 asset indicates that it has been sold. Importantly, each 

asset, in an illustrated embodiment, is linked to a respective 
description, detailed in nature and which includes information 
beyond that contained in the simple identification. A user 
can "click" on the "Allegany Mega-8" wording that is 
25 underlined, and will be hyper-linked to its detailed 

description. Although not shown in Figure 11, the detailed 
description of an asset may be substantially identical to the 
information illustrated in Figure 6. 

[00107] Screen output 232 further includes a Bid button 236, 

30 a plurality of radio selection buttons 238, a "New Search- 
button 240, and an "Add to Fantasy Fleet" button 242 having an 
associated pull down menu 244. Bid module 60 is configured to 
allow the user to select one of the assets identified in the 
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market search for placement of a bid. To place a bid on an 
asset, the user first selects the asset using the radio 
buttons 238. Thereafter, the user "clicks" on Bid button 236, 
which invokes bid module 60. The Move or Add to fantasy fleet 
5 button 242 will be described in greater detail below in 

connection with the simulated fleet feature of the present 
invention . 

[00108] Figure 12 shows a screen output 245 generated by bid 

module 60. In a constructed embodiment, output 245 includes 
10 the detailed description of the asset, similar to Figure 6, 
but which has been omitted from Figure 12 for clarity. Bid 
module 60 provides transaction options: a purchase transaction 
option 246, a lease transaction option 248, and a rental 
transaction option 250. The desired transaction is selected 
15 by the user through the radio buttons. In the illustrated 

embodiment, a "Buy' 7 transaction has been selected by the user. 
[00109] When the selected transaction is a purchase 

transaction, bid module 60 is configured to prompt the user 
for a bid price offered for the selected asset, which is 
20 entered in input box 252. As used herein, the wording 

"prompt" merely means to provide a mechanism or means to 
accept the bid price, and does not suggest or require some 
active activity, such as a blinking input box, input wizard or 
the like. 

25 [00110] When the selected transaction is a lease 

transaction, bid module 60 is further configured to prompt the 
user to select a lease term, a lease type, and a monthly lease 
amount offered for the selected asset. As illustrated in 
exemplary fashion in Figure 12, the lease term may be input 

30 through a pull down' menu 254, the lease type may be input 

through pull down menu 256, and the monthly lease amount may 
be entered (e.g., keyboard) in box 25 8. In a constructed 
embodiment, the lease term may be one of a 24-month, 36 month, 
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4 8 month, 60 month, and 72 month term. Further, in a 
constructed embodiment, the lease type may be one of a 
category 1, category 2, category 3, fixed-ten (10%) percent, 
fixed- twenty percent (2 0%) , buyout -new, buyout -used, category 
4, category 5, category 6, and category 7 type leases. Lease 
types may be totally configurable. Of course, other options 
may be used or offered to the user, depending on the asset, 
market conditions, etc. To facilitate the bidding process, 
bid module 60 further includes a lease calculator tool, which 
may be invoked by "clicking" on the Lease Calculator button 
262. The lease calculator tool allows the user to specify 
lease term and lease type, and enter a third parameter, either 
a monthly payment or a total lease amount, and have the lease 
calculator calculate a fourth parameter, the other one of the 
lease amount and monthly payment. The calculated amount can 
be directly transferred to the monthly lease amount box 258. 
[00111] When the selected transaction is a rental 

transaction, bid module 60 is further configured to prompt the 
user for a monthly rental price offered for the selected 
asset, which may be entered in box 260. The user may submit 
the bid by "clicking" on the "Submit Bid" button 264. 
[00112] Bid module 60 is further configured to generate a 

bid history (not shown) for each asset that has been posted in 
market database 36. The bid history comprises a listing of 
each bid made by the users of system 20 on a particular asset. 
The bid history includes a detail of the submitted bid (e.g., 
by whom, price offered, etc.) . Bid module 60 is also • 
configured to allow the user that posts the asset in the 
market database (e.g., the leasing company), to retrieve the 
bid history, to review the bids contained in the listing, and 
finally to accept one of the bids to thereby complete the 
offered transaction. 
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[00113] Through the foregoing, accumulated information 

acquired from the tracking and managing of assets can be 
leveraged to increase financial return when such assets come 
off of lease and must be disposed of. 

[00114] In some cases, it is desirable to have a subsystem 

3 00 that runs on a periodic basis, which compares a subset of 
all assets 22 within system 20 with a series of pre-defined 
conditions 3 02 to determine if an action needs to be taken 
with respect to asset disposition. The pre-defined conditions 
include either a time variable or a cost variable. For 
example, one condition using a time variable involves the 
natural end of an asset lease - including, for example a set 
time period such as six (6) months prior to an end of a lease. 
Thus, the time variable is associated with the passage of 
time. A second condition using a time variable includes a 
situation such as when a particular asset has excessive usage 
compared to its time (e.g., hours) in service. An example 
condition using a cost variable involves an over usage of an 
asset, wherein based on such over usage, penalties begin to be 
invoked. Another example condition using a cost variable 
results when an analysis shows that the cost of leasing an 
asset appears to be higher than a threshold level when 
compared to other asset usage options that are immediately 
available to the asset user (e.g., a lessee) such as by 
5 purchasing more assets at a lower cost or reallocating 

existing assets between locations. It is also possible to 
develop pre-defined conditions using a combination of time and 
cost variables. For example, an excessive usage criteria may 
involve both a time element and a cost element. 
0 [00115] As illustrated in Figure 15/ if no pre-defined 

conditions are met at point 302 subsystem 300 terminates at 
point 304. Alternatively, if a condition is met, subsystem 
300 proposes a hierarchy of options at point 306 as to a 
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proposed action, for- the benefit of the asset user such as a 
lessee. The data for making the various options comes from 
market database 36, global asset database 38, fleet database 
40 or asset database 42. As noted above, these may actually 
be one or more separate databases. Typically, the information 
used to determine the pre-defined conditions and available 
options comes from asset identification data, maintenance 
history data, and lease term. The identification data 
includes asset make/model and serial number. Lease term may 
be determined by an analysis of at least two of three pieces 
of data, namely, lease start date, lease end date, and the 
length of time between the lease start and end dates. 
[00116] Possible options based on pre-defined conditions 

include: the leasing of additional assets to reduce the amount 
of use of a pre-existing asset; a comparison of a cost of. 
leasing an asset with a threshold level representing lower 
cost alternatives; the leasing of additional assets; asset 
lease renewal; asset purchase or buyout; asset disposal; asset 
sale; or asset sale and purchase of replacement assets. 
Associated with each option is. the cost of invoking the option 
and the reasons why the system, in accordance with its review 
of each option in accordance with the pre-defined rules, 
believes that the selected hierarchy of options is preferred. 
Most often the controlling factor will be total price to the 
asset user for the collection of assets performing the same or 
similar function. 

[00117] Before suggesting lease renewal, for example, the 

system preferably reviews a database of historical information 
about lease considerations involving similar assets and 
» alternatively consults with other lessor representatives to 
determine a quote for renewing the lease term. If this price 
is lower than other options, it will be listed first. 
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[00118] Before suggesting the leasing of additional assets , 

the system preferably reviews current pricing information and 
asset availability. If the system determines that the overall 
cost to the asset user will decrease the most if this option 
is selected, then it will be listed first 

[00119] In the case of buyout, subsystem 3 00 may review any 

existing contract language between the lessor and lessee 
concerning a fixed price. If there is no such price, it may 
then review historical information concerning buyouts 
involving similar assets potentially taking into account such 
things as asset condition and usage patterns to make a 
recommendation , 

[00120] Finally, before suggesting lease disposal, subsystem 

300 considers the cost, if any, with disposing of an asset 22, 
so that the information may be provided to the asset user. 
[00121] Once subsystem 3 00 determines the hierarchy of 

possible options to send to an asset user concerning an asset 
at point 3 06, notification is sent to an account manager of 
the lessor having a relationship with the asset user. The 
""account manager is given a report 308 that includes each asset 
meeting the pre-defined condition and a link to specific 
information about the asset including asset description, 
utilization, maintenance history and costs. If there are a 
number of assets, the assets may be grouped by asset type, 
time until lease termination, cost, usage, lessee company, 
asset location, or any other desired criteria. A group 
manager, to whom an account manager reports, may see assets 
associated with each account manager. The group manager can 
sort assets in any manner available to an account manager, but 
has the additional capability to sort assets in accordance 
with each account manager. 
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[00122] In general, the account manager will review one or 

more of the proposed options generated by subsystem 3 02 to 
confirm his agreement with both the hierarchy and the 
specifics of each option as shown by point 310. 

Alternatively, the account manager may just review the present 
option to confirm his agreement with the specific proposal. 
In some cases it may be desirable to bypass the account 
manager to have it sent directly to the asset user. However, 
in many cases, minor adjustments may be appropriate before the 
option details are transmitted to the asset user. Depending 
on the nature of the refinements, however, it may be desirable 
to refine the pre-defined rules in general or for a particular 
asset user if the nature of the refinement represents 
particular preferences of such a user. For example, a 
particular customer may never wish to buy an asset 22 under 
any circumstances so an option related to a buyout should 
never be presented to that customer. Thus, in a preferred 
embodiment of the invention, the proposed options are manually 
reviewed, and in the case where modifications are made, the 
rational for the modifications are incorporated back into 
subsystem 300. Thus, a rejection of a hierarchy of options 
generates feedback for selectively modifying the availability 
of future options by system 300 at either a global or customer 
level . 

[00123] Once the option hierarchy is finalized, the options 

are sent in descending order of expected acceptance, as 
discussed in more detail below, to an asset user by way of 
electronic mail, facsimile, regular mail, or even a link 
available on a web site accessible to the asset user. Two-way 
electronic communications with simple pre-programmed responses 
available to the asset user are preferred since no manual 
updating of subsystem 300 is then required. 
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[00124] Figure- 16 illustrates an example of a report 308 in 

the form of an interactive screen available to^ the account 
manager or group manager with various columns. Typically, 
report 308 is accessed using a client computer 24 and web 
server 30, as discussed above. Column 312 shows a listing of 
various lessee companies. Column 314, which is broken into 
three sub-columns, relates to end of lease options. The first 
sub-column gives the months remaining before an option must be 
selected while the second sub-column gives the actual deadline 
date. The third sub- column is a hyperlink, which when 
clicked, gives detail on the various options available and 
their hierarchy, as well as specific lease related details 
such as pricing or proposed lease term. The detail can be 
optionally edited, subject to any internal lessor approval 
process. Column 316 gives facility information. Broken into 
two sub-columns, the first sub-column gives city and state 
information while the detail information associated with asset 
22 and its location is accessible by the hyperlink of the 
second sub-column. Column 318 includes the asset information 
in sub- column- format such as asset make, model and serial 
number. More complete information including full maintenance 
history, lease information, and the like is available by way 
of the detail hyperlink. Finally, column 320 gives the status 
of various communications sent or received from an asset user. 
5 Communication status 320 represents the nature of all 

communications sent or received back from an asset user and 
the option currently pending from the hierarchical list of 
options available for the particular situation. A response by 
the asset user triggers automatically the next response by 
0 subsystem 300 for the particular asset as discussed by way of 
example below . 

[00125] In Figure 16, assets 22 are listed individually by 

each row, but also sorted by lessee company. In the present 
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example, assets 22 meeting a pre-defined condition associated 
with companies LOF and Zen's are activated for review. 
[00126] It is also possible for a specific lessee to see a 

similar screen if accessing the information by way of a client 
computer 24 and web server 30. However, in such a case, the 
information would be limited to leases associated with the 
particular lessee organization. It also facilitates follow up 
between an asset user and a lessor to avoid undesirable delay 
in determining what to do with an asset. 

[00127] If an asset user rejects a particular recommendation 

as shown by a change in communication status, the next best 
option is then presented to the account manager for review and 
transmission to an asset user until a decision is made. 
[00128] In the example of Figure 15, the option of accepting 

a new lease involving new asset is first recommended to the 
account manager at point 322. Typically, this is called "New 
Item" in column 320. If the account manager agrees with the 
proposed terms including cost and duration, he sends it to the 
asset user. Column 320 is updated to reflect "New Item Sent", 
If the asset user accepts it ("Customer Accepts New Lease" in 
column) at point 324, then a new asset is delivered to the 
asset user at point 32 6, the off r leased asset is picked up and 
moved to storage for re-sale or re-lease to a different party 
at point 328. Subsystem 300 then forks to point 390, where 
system 2 0 is updated with the data related to the assets at 
point 392 and terminates at point 394. 

[00129] If the asset user rejects the new lease option 

("Customer Declines New Lease" in column 320) at decision 
point 324, then the subsystem 300 recommends based on the next 
most -favorable option, in this example that the asset user 
renews its lease of the asset ("Renew Lease" in column 320) , 
which the account manager reviews in the form of an updated 
report at point 332. If he agrees with the proposed terms 
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including cost and duration, then it is sent to the asset : user 
("Renew Lease Sent' 7 in column 320) . If the asset user accepts 
this option ("Customer Accepts Renewal" in column 320) at 
decision point 334, then renewal documentation is sent to the 
asset user at point 33 6 with subsystem 30 0 forking to point 
390 as above. If the asset user rejects the second option 
("Customer Declines Renewal" in column 32 0) , subsystem 3 00 
then suggests to the account manager that there be a buy out 
of the asset by the asset user ("Buyout")/ which is reviewed 
at point 3 38. Once again, if the account manager agrees, the 
option with relevant detail on the terms of the proposed 
buyout is sent to the asset user ("Buyout Option Sent" in 
column 320) . If the asset user accepts that option ("Customer 
Accepts Buyout") at decision point 340 and the generated 
buyout price, then the asset is- sold to the asset user as 
shown by point 342 with the subsystem forking to point 390. 
[00130] Finally, if the asset user does not accept any of 

the prior options at point 340, then subsystem 300 sends out a 
request to the asset user concerning when the asset should be 
picked up ("Pickup Timing- Sent" in column 32 0) at point 3 44, 
and the asset is picked up at point 346 at the time and 
location agreed to at point 344. with subsystem 300 forking to 
point 3 90. 

[00131] No interaction by the account manager is required 

once all of the remaining options have been provided. In this 
example, subsystem 3 00 determined that the addition of assets 
22 while maintaining the existing asset was not a viable 
option, so it was not presented for consideration. 
[00132] While Figure 15 exemplifies one possible course of 

conduct between a- lessor and lessee with respect to a 
particular asset 22, the actual hierarchy of options will 
depend on the asset, characteristics of the asset user (e.g., 
e.g., a local versus a national company) current market 



65678-0042 (5672 DCCSP) 



conditions (e.g., asset availability on the open market and - 
pricing) , and the nature of the relationship between lessee 
and lessor (e.g., the existence of any particular preferred 
arrangement for the benefit of the asset user) . Further, even 
after an asset user agrees to an option, further negotiation 
as to cost and lease timing may be required. For example, as 
shown in Figure. 16, column 320 shows additional status 
entries: "New Quote Sent", "New Quote Returned" and "Quote 
Accepted", reflecting additional level of detail available as 
part of the operation of subsystem 300. 

[00133] In summary, subsystem 300 works as follows. A 

database is configured and information associated with a 
plurality of assets 22 is stored in the database. Subsystem 
3 00 analyzes the information in accordance with a set of pre- 
defined conditions. When a pre-defined condition is met, the 
subsystem recommends asset disposition using a hierarchy of 
disposition options, and the conditions and the options are 
selected to reduce expense and to maximize the return on 
investment for the asset user. The hierarchy of options are 
typically manually checked and confirmed, and a rejection of 
the hierarchy of options generates feedback with the system 
modifying as appropriate the availability of future options. 

Simulated ("Fantasy") Fleet 

[00134] Conventional asset management systems lack effective 
tools for conducting "what if" analyses i.e., modeling a 
simulated fleet containing both actual assets and proposed 
assets. The invention overcomes the shortcomings inherent in 
conventional systems by providing an electronic system 2 0 for 
modeling a simulated fleet. For example, if two older 
machines, each with high maintenance costs, are replaced by 
two newer machines with lower maintenance costs, but with 
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higher lease costs, what effect would such a change make on 
the overall performance , of the fleet? The Fantasy Fleet 
simulator of the present invention enables computer-based 
modeling that assists answering such questions. 

[00135] As shown in Figure 3, a Fantasy Fleet may be created 

in the same manner as an actual fleet (a fleet with real 
assets). A fantasy fleet may be created by "clicking" on a 
Create button 108, which invokes the simulated fleet module 
50, which in turn prompts the user to input a fantasy fleet 
name, as well as a location. Once the fantasy fleet has been 
created, assets may then be added. 

[00136] To promote the greatest amount of flexibility 

possible, electronic system 20, to implement the "Fantasy" 
fleet feature, includes a simulated fleet configuration unit 
that comprises multiple interfaces/modules for setting up and 
adding assets to the fantasy fleet. These interfaces/modules 
include at least one of an add-asset feature of simulated 
fleet module 50, an add-to fleet feature via the fleet search 
module 54, an add-to-fleet feature via market search module 
58, and a step-by-step entry system of the fleet builder 
module (not shown) , accessible via the "Fleet Builder" button 
on the user's start page 66. Each will be described in turn. 
[00137] First, the add-asset feature of simulated fleet 

module 50 may be used. A user may "click" on link 116 in 
Figure 3, which causes simulated fleet module 50 to generate a 
screen output 266 --an asset view-- as shown in Figure 13. 
The user interface illustrated in Figure 13 operates in 
substantially the same manner as the user interface 
illustrated in Figure 4 for assets contained in an existing 
fleet. For example, the user, by "clicking" on the "Add- 
Asset" button 268, causes simulated fleet module 50 to present 
an input data dialog, in accordance with the flowchart of 
Figure 5, for adding an asset. The user then configures the 
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asset in the same manner as described above for- an existing 
fleet. 

[00138] Second, the add-to- fleet feature of fleet search 

module 54 may be used. As shown in Figure 9, a user can 
search his fleets by selecting search button 82 from the 
user's start page 66 (Figure 3), which invokes fleet search 
module 54. The search results contain an identification of 
the assets that are available for selection. Selection may 
occur, for example, through the use of radio buttons, as shown 
in Figure 9. The user may then select a destination- simulated 
fleet through the use of pull down menu 270, and then add the 
chosen asset to the desired fantasy fleet by "clicking" on Add 
button 272 . 

[00139] Third, the add-to-fleet feature of .market search 

module 58 may be used. The further method for adding assets 
to a fantasy fleet involves conducting a market search, using 
market search module 56, as illustrated in Figure 10. Then, 
the user adds assets by selecting the desired destination 
fantasy fleet through pull down menu 244, and "clicking" on 
the Add 1 button 242. Through this approach, items available in 
market database 3 6 may be added to the fantasy fleet. 
[00140] Fourth, a user may use the fleet builder wizard to 

create a fantasy fleet and configure and add assets. The 
fleet builder wizard may be invoked by "clicking" on the 
"Fleet Builder" button 86 on the user's start page 66. This 
step-by-step entry system leads the user along, prompting for 
a fleet name, and location, an indication that it is a fantasy 
fleet, and prompts to add an asset. The add asset feature of 
the "fleet builder" dialog is substantially the same as the 
"add asset" feature of the current fleet module 52, described 
above (e.g., Figure 5). 

[00141] Figure 14 shows a report 274 generated by reporting 

and analysis module 62. In particular, each asset listed in 
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the report has an associated, plurality of parameters, such as 
average monthly usage hours, total maintenance cost, hourly 
maintenance cost, total lease cost, total operating cost, 
total hourly cost, percent utilization, etc. A user can 
invoke the reporting and analysis module 62 by selecting the 
Reporting button 92 from the "start" page 66 shown in Figure 
3. The user may then select the target fleet (existing or 
fantasy) for which the report (s) will be generated. A user 
can evaluate changes made to an existing fleet by generating a 
report for an existing fleet, configuring a simulated fleet ' 
reflecting the proposed changes, and then generating a second 
report . 

[00142] The two reports can be compared and decisions made 

based on the results of the comparison. In the report shown 
in Figure 14, the assets enclosed by dashed-line box 276 are 
part of an existing fleet for which a report (not shown) has 
already been or will be generated by module 62. The assets 
shown in dashed-line box 278 are proposed additions to the 
existing fleet. The combination of the assets in dashed-line 
box 276, and dashed-line box 278 constitute the simulated or 
fantasy fleet. One exemplary parameter is total hourly cost 
280. Reporting and analysis module 62 is configured to 
generate report 274 having a composite output 282 that is 
characteristic of all the assets in the simulated fleet. The 
5 composite total hourly cost 2 82 can then be compared to the 

corresponding total hourly cost for the existing fleet (in the 
other report) to make an evaluation of the proposed changes. 
Another composite output shown in Figure 14 is percent 
utilization 284. It should be appreciated that some of the 
0 composite parameter values are determined by reporting and 
analyzing module 62 according to an arithmetic sum function, 
such as the total maintenance cost parameter. Reporting and 
analyzing module 62 is further configured to determine other 
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composite parameters, such as hourly maintenance cost, 
utilization, and total hourly cost, according to an arithmetic 
average function. The parameters dealing with money amounts 
(e.g., dollars) required or desirable to make an asset 
acquisition determination may be characterized as a financial 
figure of merit. Other parameters, such as utilization 
percent, may be characterized as a performance figure of 
merit . 

[00143] To the extent that the specific assets included in 

the simulated fleet have actual usage, performance, 
utilization, and cost data associated therewith, then such 
information is used by reporting and analyzing module 62 in 
computing composite values. However, when the assets are of 
the type that have no asset-specific data associated 
therewith, then profiled asset specification data is used in 
performing the analysis. Additionally, when preconf igured 
assets from preconf igured database 42 are included in a 
simulated fleet (or in an actual fleet) , then composite data 
for assets of a similar type are used by module 62 for 
analysis purposes. — 

[00144] In accordance with the provisions of the patent 

statutes, the principle and mode of operation of this 
invention have been explained and illustrated in several 
preferred embodiments. However, it must be understood that 
this invention may be practiced otherwise than as specifically 
explained and illustrated without departing from its spirit 
and scope. 
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CLAIMS 

What is claimed is:. 

1. An electronic system for facilitating disposition of 
an asset currently under lease by an asset user, comprising: 

at least one database configured to store 
information associated with a plurality of assets; 

a set of pre-defined conditions related to a 
recommendation of asset disposition based on an automated 
analysis of said information within said system, at least one 
of said conditions being met; and 

a hierarchy of disposition options generated by said 
system based on said at least one of said conditions, wherein 
said conditions and said options are chosen to reduce expense 
by maximizing return on investment to the asset user. 

2. An electronic system as recited in claim 1, wherein 
said pre-defined conditions include at least one of a time 
variable and a cost variable. 

3. An electronic system as recited in claim 2, wherein 
said time variable comprises a passage of time, said at least 
one of said conditions being met when an asset approaches the 
end of a lease term. 

4. An electronic system as recited in claim 3, wherein 
said options include lease renewal; asset buyout; and asset 
return. 
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5. An electronic system as recited in claim 3, wherein 
said time variable comprises asset usage within a 
predetermined period of time, said at least one of said 
conditions being met when asset use exceeds a usage criteria 
based on time in service. 

6. An electronic system as recited in claim 5, wherein 
said options include the leasing of additional assets to 
reduce the amount of use of a pre-existing asset. 

7. An electronic system as recited in claim 2, wherein 
said cost variable includes a comparison of a cost of leasing 
an asset with a threshold level representing lower cost 
alternatives. 

8. An electronic system as recited in claim 7, wherein 
said options include the leasing of additional assets. 

9. An electronic system as recited in claim 1, wherein 
said information includes asset-identification data, 
maintenance history data, and lease term. 

10. An electronic system as recited in claim 9, wherein 
said identification data comprises an asset make/model and 
serial number. 

11. An electronic system as recited in claim 9, wherein 
said lease term includes at least two of a lease start date, 
lease termination date, and a length of time between said 
lease start date and said lease termination date. 
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12. An electronic system as recited in claim 1, further 
comprising a manual check and confirmation of said hierarchy • 
of options, wherein a rejection of said hierarchy generates 
feedback selectively modifying said availability of future 
options by said system. 

13. An electronic system as recited in claim 1, wherein 
said options are presented to the asset user for consideration 
in order of expected acceptance. 

14. An electronic system as recited in claim 1, wherein 
one of said options is a new lease, wherein upon acceptance of 
said new lease, a new asset is delivered to the asset user, an 
off-leased asset is picked up, and said off-leased asset is 
disposed. 

15. An electronic -system as recited in claim 1, wherein 
one of said options is a renewed lease, wherein upon 
acceptance of said renewed lease renewal documents are 
executed by the asset user. 

16. An electronic system as recited in claim 1, wherein 
one of said options is an asset buyout, wherein upon 
acceptance of said asset buyout, the asset is purchased. 
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17. An electronic system for facilitating disposition of 
an asset currently under lease by an asset user, comprising: . 

at least one database configured to store 
information associated with a plurality of assets; 

a set of pre-defined conditions related to a 
recommendation of asset disposition based on an automated 
analysis of said information within said system, each of said 
conditions comprising at least one of a time variable and a 
cost variable, at least one of said conditions being met; 

a hierarchy of disposition options generated by said 
system based on said at least one of said conditions, wherein 
said conditions and said option's are chosen to reduce expense 
by maximizing return on investment to the asset user; and 

a manual check and confirmation of said hierarchy of 
options, wherein a rejection of said hierarchy generates 
feedback selectively modifying said availability of future 
options by said system. 

18. An electronic system as recited in claim 17, wherein said 
time variable comprising a passage of time, said at least one 
of said conditions being met when an asset approaches the end 
of a lease term or when asset usage exceeds a usage criteria 
based on time in service; and 

said cost viable including a comparison of a cost of 
leasing an asset with a threshold level representing lower 
cost alternatives. 
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19. An electronic system as recited in claim 17, said 
information including asset identification data, maintenance 
history data, and lease term, wherein said identification data 
comprises an asset make /model and serial number, and said 
lease term includes at least two of a lease start date, a 
lease termination date, and a length of time between said 
lease start date and said lease termination date. 

20. An electronic system as recited in claim 17, wherein 
said options are presented to the asset user for consideration 
in order of expected acceptance, and wherein, 

a first of said options comprises a new lease such that 
upon acceptance of said new lease, a new asset is delivered to 
the asset user, an off-leased asset is picked up, and said 
off-leased asset is disposed, 

a second of said options is a renewed lease such that 
upon acceptance of said renewed lease renewal documents are 
executed by the asset user, and 

a third of said options is an asset buyout such that upon 
acceptance of said asset buyout, the asset is purchased. 



65678-0042 (5672 DCCSP) 

21. A method for facilitating disposition of an asset 
currently under lease an asset user, comprising the steps of: 

configuring at least one database and storing 
information associated with a plurality of assets; 

analyzing said information in accordance with a set 
of pre-defined conditions, each of said conditions comprising 
at least one of a time variable and a cost variable; 

meeting at least one of said pre-defined conditions; 

recommending asset disposition using a hierarchy of 
disposition options; and 

selecting said conditions and said options by 
reducing expense and maximizing return on investment to the 
asset user. 

22, A method as recited in claim 21, further 
comprising the step of: 

instituting a manual check and confirmation of said 
hierarchy of options; and 

said rejection of said hierarchy generating 
feedback, selectively modifying said availability of future 
options by said system. 
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23. An electronic system as recited in claim 21, 
including the further step presenting said hierarchy of . . 
options to the asset user for consideration in order of 
expected acceptance, and wherein, 
5 a first of said options comprises a new lease such that 

upon accepting said new lease, delivering a new asset to the 
asset user and picking up and disposing of an off-leased 
asset , 

a second of said options is a renewed lease such that 
10 upon accepting said renewed lease renewal, the asset user 
executing renewal documents, and 

a third of said options is an asset buyout such that upon 
accepting said asset buyout, the asset user purchases the 
asset . 

15 
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ABSTRACT OF THE DISCLOSURE 

A database is configured and information associated with 
a plurality of assets is stored in the database. The system 
5 automatically analyzes the information in accordance with a 
set of pre-defined conditions. When a pre-defined condition 
is met, the subsystem recommends asset disposition using a 
hierarchy of disposition options, and the conditions and the 
options are selected to reduce expense and to maximize the 
10 return on investment for the asset user. The hierarchy of 

options are typically manually checked and confirmed, and a 
rejection of the hierarchy of options generates feedback with 
the system modifying as appropriate the availability of future 
options. 

15 
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